public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zack@codesourcery.com>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: Neil Booth <neil@daikokuya.demon.co.uk>,
	pfk@RZ.uni-jena.de, gcc@gcc.gnu.org
Subject: Re: Proposal
Date: Tue, 18 Sep 2001 10:21:00 -0000	[thread overview]
Message-ID: <20010918102000.D3510@codesourcery.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0109181019360.11043-100000@kern.srcf.societies.cam.ac.uk>

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

  reply	other threads:[~2001-09-18 10:21 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-15 11:45 Proposal Frank Klemm
2001-09-15 12:15 ` Proposal Gerald Pfeifer
2001-09-17 16:00 ` Proposal Neil Booth
2001-09-18  2:30   ` Proposal Joseph S. Myers
2001-09-18 10:21     ` Zack Weinberg [this message]
2001-09-18 11:14       ` Proposal Joseph S. Myers
2001-09-18 22:20         ` Proposal Zack Weinberg
2001-09-19  1:14           ` Proposal Joseph S. Myers
2001-09-18 12:23       ` Proposal Frank Klemm
2001-09-18 22:37         ` Proposal Zack Weinberg
2001-09-19  0:02           ` Proposal Neil Booth
2001-09-19  2:23             ` Proposal Tim Hollebeek
2001-09-19  2:41               ` Proposal Richard Earnshaw
2001-09-19 13:38         ` Proposal Joe Buck
2001-09-18 15:35       ` Proposal Robert Lipe
2001-09-18 16:59         ` Proposal Russ Allbery
2001-09-20 11:17           ` Proposal Kai Henningsen
2001-09-20 12:34             ` Proposal Russ Allbery
2001-09-18  9:48   ` Proposal Frank Klemm
2001-09-18 11:06     ` Proposal Neil Booth
2001-09-18 11:37     ` Proposal Kevin Handy
2001-09-18 15:48       ` Proposal Neil Booth
2001-09-18 15:55         ` Proposal Toon Moene
2001-09-27  5:39     ` Proposal Alexandre Oliva
2001-09-27  7:09       ` Proposal Frank Klemm
2001-09-27 16:22         ` Proposal Zack Weinberg
2001-09-29 15:45           ` Proposal Frank Klemm
2001-09-30  9:35             ` Proposal Zack Weinberg
2001-09-27 16:36         ` Proposal Neil Booth
2001-09-29 15:45           ` Proposal Frank Klemm
2001-09-29 17:22             ` Proposal Daniel Jacobowitz
2001-09-29 18:32               ` OT: Proposal Michael Matz
2001-10-03  3:52         ` Proposal Fergus Henderson
2001-09-17  8:55 Proposal Thomas R. Truscott
2001-09-18  9:32 Proposal dewar
2001-09-18 12:30 Proposal dewar
2001-09-18 23:01 ` Proposal Zack Weinberg
2001-09-19  0:06 Proposal dewar
2001-09-19  2:34 Proposal dewar
2001-09-19  2:44 Proposal dewar
2012-09-03 15:16 Proposal Afeez Basit
2012-09-03 18:35 Proposal Afeez Basit
2013-06-26 17:41 Proposal Barrister David Lopez Esq
2013-06-26 18:15 ` Proposal Paolo Carlini
2013-06-26 18:40   ` Proposal Daniel Santos
2013-06-26 17:47 Proposal Barrister David Lopez Esq

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010918102000.D3510@codesourcery.com \
    --to=zack@codesourcery.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jsm28@cam.ac.uk \
    --cc=neil@daikokuya.demon.co.uk \
    --cc=pfk@RZ.uni-jena.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).