This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: statement expressions



>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

    Linus> However, there is one thing an inline function simply
    Linus> _cannot_ do. Not now, not in the near future. And that's
    Linus> using "typeof". Which is a very powerful thing indeed,
    Linus> often giving a nicer interface than any amount of
    Linus> overloading could ever do, with simpler semantics.

What you say is true: statement-expression + typeof > inline.

(C++, of course, solves this problem via the use of templates.  But,
even I would not propose introducing templates into C!)

I'm not convinced, however, that this rarely used functionality is
worth the costs.

(I did a lot of work on funky programming languages in the past.  I
love cool language features, and nifty languages: Haskell, ML, Prolog,
Python, etc.  All of these languages have wonderful constructs.  I'm
by no means of the opinion that C and C++, in their ISO-standardized
form, are the only true languages.  I am, however, disturbed by
language extensions which have poorly-defined semantics (including
some in C++!), or which don't seem in the spirit of the language, or
which have overly high implementation costs relative to the power they
bring.  The point of this overly wordy paragraph is that I'm not
arguing against this construct because it's non-standard, or because
it's not powerful, it's because I don't think the benefits outweigh
the costs.  I believe we can deliver more reliable, better optimizing,
easier to use compilers if we eliminate some of the obscure
functionality in the compiler that has proven historically to be
confusing, difficult to maintain, semantically problematic, and a
source of many a bug.)

    Linus> So I think you're too harsh on statement expressions.  They
    Linus> are truly a nice shorthand.  I don't see any badly defined
    Linus> semantics about them in general: if the only issue with
    Linus> them is strange results from local labels, then deprecating
    Linus> them sounds like much too harsh a treatment.

That's by no means the only oddity.  In C++, especially, there are
very serious semantic issues.  The impact of that is that
statement-expressions in C header files (designed also to be included
in C++, like those in glibc) are seriously problematic.

I guess I agree with you -- up to a point.  I think that in C the
associated nastinesses are fewer, and you're certainly right that
there are lots of ways to shoot yourself in the foot in C (or C++!),
and that the oddities involving gotos out of statement expression are
just one such way.

I do not believe, however, that the C++ issues are easily fixed.  (Not
only from an implementation point of view -- but even from a language
semantics point of view.)  The upshot of this is that I believe that
statement-epxressions should be eliminated from header files that
might be included in C++ programs, i.e., anything in /usr/include.

So, perhaps I should suggest a) deprecating the feature in C++, and b)
removing usage of the feature from the glibc and kernel headers
instead.  I have a feeling that won't make you any happier,
though. :-) And, it's unfortunate to have GNU C be less a subset of
GNU C++ than ISO C is of ISO C++.

    Linus> So if you want to clean up the language, why not deprecate
    Linus> and eventually get rid of nested functions instead 

You'll get only agreement from me.  But, I don't find these things
mutually exclusive: I'd be more than happy to deprecate *both*
features. :-)

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]