From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zack Weinberg To: "Joseph S. Myers" Cc: Neil Booth , pfk@RZ.uni-jena.de, gcc@gcc.gnu.org Subject: Re: Proposal Date: Tue, 18 Sep 2001 10:21:00 -0000 Message-id: <20010918102000.D3510@codesourcery.com> References: <20010917235928.A11347@daikokuya.demon.co.uk> X-SW-Source: 2001-09/msg00715.html On Tue, Sep 18, 2001 at 10:28:50AM +0100, Joseph S. Myers wrote: > On Mon, 17 Sep 2001, Neil Booth wrote: > > > This is possibly a good idea. It's a trivial patch to implement it > > (c-lex.c I think, unless Zack finally applies his number patch); a > > comment even exists in the code mentioning that it might be a future > > extension. > > However, we shouldn't add it to GCC yet. Since this feature would not > actually allow you to do something that couldn't reasonably be done before > or make it substantially simpler to do so, and since it might be > appropriate for a future version of the standard, a more appropriate > procedure would be: [snip] I can tell you exactly what comp.std.c will say: Go away, implement it, and get several years of experience with the extension, then come back with a formal proposal. The suggested extension (_ as a separator in numbers) was actually proposed on comp.std.c just before C99 was finalized, and they said just that. We have also been around this particular wheel with other extensions. Does anyone remember __norestrict? Your recipe is equivalent in practice to "we will add no (more) extensions, ever." Which is a legitimate position to take, but only by coming out and saying so. It is unfair to run people through a lengthy bureaucratic procedure that appears to offer the possibility of adding an extension, but will always result in the extension being rejected. I'd also point out that very few people have access to the standard; yes, ANSI sells copies for not-totally-outrageous sums, but many don't know that and the cost may still be too high. Counterproposal: Require people who propose extensions to document their semantics in detail, to the point where a formal proposal _could_ be made to the standard committee, but don't make them get beaten up by comp.std.c. Debate the extension here and in the user community. If there's agreement that it would be useful, it would not clash with present or future standard behavior, and it would not cause unfortunate consequences down the road, then we implement it. For all extensions, present or proposed, we either write up a formal proposal to the standard committee, or we deprecate the extension. The proposals are stored on the website. Should we ever be in the position of having representation on the committee (which I believe we currently do not) we can then submit them. zw