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 22:20:00 -0000 Message-id: <20010918221948.I12089@codesourcery.com> References: <20010918102000.D3510@codesourcery.com> X-SW-Source: 2001-09/msg00744.html On Tue, Sep 18, 2001 at 07:12:21PM +0100, Joseph S. Myers wrote: > On Tue, 18 Sep 2001, Zack Weinberg wrote: > > > 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. > > Just before C99 was finalized wasn't an appropriate time for proposing new > features; nor is now Right - which is precisely why we *shouldn't* make proposers of extensions run the gauntlet of comp.std.c or the WG14 reflector. I would like to see us in a position to propose a set of useful improvements to the standard in the next cycle, and that means experimenting - both with our existing extensions and with new ones. I'm glad to hear the UK National Body is working on the existing issues with the C standard, but that really doesn't affect the original poster's proposal, which is about as independent of the existing problems as you can get. Which isn't to say that it is perfect - I have concerns, though I like the idea in principle. (see other message) > > 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. > > The presumption must be against extensions because of the bad history of > problems caused by extensions that are poorly defined or later cause > problems in their interaction with new language features. Certainly the presumption is against them, and in fact I think a position of "no additional extensions at all" is extreme but reasonable. What I object to is your proposed procedure, which _appears_ to be open to new extensions, but in practice is closed, and will subject the proposers of extensions to a great deal of wasted effort. Again, remember __norestrict? > > 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. > > There is work in progress towards getting it published as a normal book > (officially, not with value-subtracting annotations by Schildt) by a > normal publisher whose books appear in bookshops. (I don't have any more > information about these plans.) Oh good. > > 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 > > The proposals should be in the manual proper. I'm not sure of this; would they be useful to normal users of GCC? Standardization proposals tend to be written in standardese and therefore are not suitable as end-user documentation. Keep 'em in the tree, sure. ... > (so that ISO have to negotiate with the FSF alone about the > inclusion of such text in the standard, and this can be used as > leverage to try to free the standard). I don't think we should do that, it is likely to be counterproductive. (I.e. I suspect the response would be to reject the proposals rather than deal with the legal issues.) Efforts to make the standard freely distributable are laudable but should happen independently. zw