__typealias qualifier (was Re: type based aliasing again)

[patl AT cag.lcs.mit dot edu (Patrick J. LoPresti)]

>>>>> "mark" == Mark Mitchell <mark@codesourcery.com> writes:

 mark> I'm not convinced we need to provide a "have your cake and eat
 mark> it too" mode where you can get the benefits of the optimization
 mark> without having conforming code.  Even if you go to the troule
 mark> of adding some extra type-qualifiers, attributes, etc.,
 mark> somewhere.

Are you prepared to be convinced, or have you already made up your
mind?

 mark> Especially now that people are providing implementations of
 mark> helpful warnings, it seems fair to say "use
 mark> -fno-strict-aliasing (either because that's the default, or
 mark> otherwise) or else write conforming code".

At least a few users (e.g., Linus) disagree with you.  The code where
`__typealias' is most useful is precisely the most
performance-critical, where the programmer wants to get at memory as
raw bytes.  On a modern machine, you do this with int *, not char *.

 mark> Historically, most of our language extensions have proven
 mark> ill-specified, to have slightly odd behavior, to significantly
 mark> complicate the compiler, etc.  

I would prefer for the `__typealias' proposal to be judged on its own
merits, not on its ethnic group.

Of course, history is a useful guide.  I agree that this extension
needs be well-specified, have well-thought-out behavior, and to have a
benefit which is worth the maintenance cost.  So let's discuss these!

 mark> I'm not commenting on any specific proposal, but it's very,
 mark> very hard to get new language features right.  There tends to
 mark> be a huge maintenance cost.

But we *have* a specific proposal, with a precise spec, a prototype
implementation, and a fair rationale.  Why not debate that proposal,
instead of resorting to general arguments?

 mark> IMO, the last thing we want to do is to make GNU C a dialect
 mark> even more divergent from ANSI/ISO C.

This argues against any new extension whatsoever.  If this is the only
argument against `__typealias' and it turns out to be suffient, you
should probably document somewhere that no new GCC extensions will
ever be accepted.  It would save people's time.

 - Pat