Escape from strong typing (was: swap(x,y))

[Karl Heuer]

In article <10897 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <1545 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
>>... so that (use int)x means treat x as type int no matter what it was.
>>This is another example of keeping the tools from the programmer.
>
>No, this is another example of not knowing how to use the tools that are
>already provided.

I agree with Herman, for a change.  An lvalue take-as operator is one of the
few "universal escapes" that is not provided by C, and is not easy to fake for
the general case.  (I believe it's Modula-2 that has this feature as a builtin
operator named ESCAPE.)

>If it wasn't represented with the same number of bits as an int, what
>could this possibly mean?  If you're going to invent something, make sure
>that it is sufficiently useful first.

Those are two separate issues.  One could probably formalize the semantics via
an equivalent statement about unions.  If x has more bits than an int, it's
well-defined (though perhaps not very useful).  If it has fewer, then the
result is "undefined behavior", just as it is for unions or gross pointer
kludgery.

As for usefulness, I'll supply an anecdote.  I once wanted to write
	unsigned int copybit(unsigned int x) {
		if (x & 0x10) x |= 0x40; else x &= ~0x40;
		return (x);
	}
in such a way that the highly-optimizing compiler would generate a simple
move-bit instruction appropriate to the architecture.  An appropriate escape
operator would have allowed me to write something like
	typedef struct { unsigned int :4, src:1, :1, dst:1; } hack;
	unsigned int copybit(unsigned int x) {
		escape(x, hack).dst = escape(x, hack).src;
	}
which also exhibits the copy better than the original.  Btw, it wouldn't have
worked to write "*(hack *)&x" since the implementation passed arguments in
registers; taking the address forced a store to memory.  Nor could I use an
intentional misdeclaration of the argument ("hack copybit(hack x)"), since the
compiler didn't believe that struct types could be placed in a register.

(Yes, I'm aware of all the portability problems in the above.  For this
application it didn't matter, as long as it worked.)

But Doug actually said "sufficiently useful", and here I agree with him: it's
not worth changing the existing language.  "Fix it in `D'", as they say.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
Followups to comp.lang.misc.