Re: __typealias qualifier (was Re: type based aliasing again)

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "Patrick" == Patrick J LoPresti <patl@cag.lcs.mit.edu> writes:

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

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

The former, but I am strongly disinclined on general principles.  As
if, say, you generally find that when you ride a bicycle you tend to
hurt yourself, but now someone promises you won't hurt yourself on
this particular snazzy bicycle.  I'm willing to listen, but my
experience tells me bicycles are dangerous, speaking metaphorically.

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

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

I've been embroiled in *another* debate.  My time is limited; I can
only devote so much of it to debating.

However, I will say that I have yet to see an example that convinces
me that even the Linux kernel needs to have its cake and eat it too.
THe fast memcpy thing is a bad example; you should work on getting GCC
to optimize this for you, instead, via its support for builtin
functions, I think.  We need the example before even beginning to
consider the extension itself.  And we need to know why no other
alternative already supported by GCC (such as standard ANSI/ISO C, or
inline assembly) will do the trick in a satisfactory way.

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

I think there are very, very few new extensions that we should accept.
Especially until we do a really good job implementing and optimizing
ANSI/ISO C and C++.  It is not in the best interests of the compiler
or our users to promulgate odd extensions to GNU C.

Portability is an issue, even for GNU programs.  Practially, they are
sometimes compiled with non-GCC compilers, which often give better
performance.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com