From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Joseph S. Myers" To: Zack Weinberg Cc: Neil Booth , , Subject: Re: Proposal Date: Tue, 18 Sep 2001 11:14:00 -0000 Message-id: References: <20010918102000.D3510@codesourcery.com> X-SW-Source: 2001-09/msg00719.html 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 (too soon until at least the standard is more widely implemented; even then it may be some time before consideration of major new features is appropriate (the UK National Body has agreed a position (written by Nick Maclaren) that destabilising changes should be avoided until there is industry consensus on the interpretation of C99 (readers of comp.std.c will be familiar with his views of the problems in various areas of C)), though at least this extension is comparatively harmless in terms of interactions with others); when the time comes for C0X it should be better publicised and more attention should be paid to comp.std.c (the UK National Body has recently submitted 33 Defect Reports to WG14 (to add to the 36 already registered and present on the WG14 web site), most of them originating in problems reported to or discussed on comp.std.c). > 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. I included the qualifications about "something that couldn't reasonably be done before" and "might be appropriate for a future version of the standard" since plenty of extensions are firmly within what is undefined in the standards, e.g. asm, and others may reach the barrier of "couldn't reasonably be done before" to justify them against the risk of future problems. Another qualification would be that new instances of existing extensions aren't problematic (e.g. new built-in functions, new attributes). > 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.) > 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. We should sort out the manual assignment situation ( and ), and preferably get a special assignment for such proposals that doesn't include the licence grantback of the normal assignments (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). -- Joseph S. Myers jsm28@cam.ac.uk