This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Proposal

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:

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]