From mboxrd@z Thu Jan 1 00:00:00 1970 From: llewelly@dbritsch.dsl.xmission.com To: Stan Shebs Cc: Mark Mitchell , kenner@vlsi1.ultra.nyu.edu, meissner@cygnus.com, gcc@gcc.gnu.org Subject: Re: GCC's statement expression extension Date: Fri, 28 Jul 2000 17:49:00 -0000 Message-id: References: <10007280137.AA18028@vlsi1.ultra.nyu.edu> <20000727183800T.mitchell@codesourcery.com> <3981DA38.DDEBF61C@apple.com> <20000728122755S.mitchell@codesourcery.com> <3981F647.2FBFFD19@apple.com> X-SW-Source: 2000-07/msg00964.html Stan Shebs writes: > Mark Mitchell wrote: > > [snip] > > There are already other C extensions that > > don't work in C++. C++ is (still) a changing language. If we can > > deliver better conformance at the price of a rarely used extension, I > > bet our user-base will thank us. As a C++ programmer and user of gcc, I mostly agree with that; if glibc's use of statement experesions can be resolved, I will be content to see them go the way of nested functions and signatures. I would be happy to see computed gotos removed from C++ (can they at least be disallowed in blocks that contain calls to non-trivial constructors or destructors?) as well. However, as soon as I said that, I immediately thought of a g++ extension I do *not* want removed: allowing templates with default arguments to be used as template template parameters when the formal template template parameter has fewer arguments than the actual parameter, and the excess arguments of the actual all have defaults. This is not even a documented extension (at least, I cannot find it in gcc/extend.texi). And then I thought of another one: The extra containers and algorithms that libstdc++-v3 inherits from the sgi stl (, etc). Not exactly a g++ issue, but still an example of an extension I do not want removed. If it came down to chosing between less ICEs on legal code, and one of these extensions, I would probably choose in favor of the former, but I would like to see a request for comment posted in a more widely read forum before hand. > > *If* it's rarely-used! In the absence of a survey or widely-broadcast > announcement, you can't really know. Apple quietly dropped Objective-C++ > from OS X prereleases because we didn't think anybody used it, and > found out otherwise when we started getting messages "why can't we > compile our ObjC++ code any more?". Yuck. Sounds like a maintenance nightmare to me. [snip] > > If I understand right, there's not been an official FSF release > since they were removed - at least my 2.95 manual still describes > them. A lot of users (such as Apple) prefer to adopt only the > official releases rather than snapshots, so they won't even know > that anything has happened to signatures until the next release comes > out. Sort of. gcc 2.95.x will reject signatures unless -fhandle-signatures is passed on the command line, and even with the flag it will give a warning. One would hope that users of signatures seeing the warning would either complain or fix their code. [snip] > > I get the sense that you wish this wasn't a discussion topic, but > that's wrong thinking; if you're contemplating changing the language > accepted by the compiler, particularly by removing constructs, you > want to let as many people as possible know about it. Get a note up > on Slashdot for instance. Users will accept a lot of change, as long > as they know that it's coming. Yes, please, before you remove any extensions - or add any new extensions - make announcements in widely read forums, and ask for user input. Anyway, I had thought: how hard would it be to grab source tarballs of a few large C++ projects (like KDE), and scan them for uses of extensions (statement expressions, for example) that are under consideration for removal?