Re: Proposal

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

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
(<URL:http://gcc.gnu.org/ml/gcc/2000-11/msg00753.html> and
<URL:http://gcc.gnu.org/ml/gcc/2000-11/msg00872.html>), 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