public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Robert Dewar <dewar@gnat.com>
To: Andrew Haley <aph@redhat.com>
Cc: Mark Mitchell <mark@codesourcery.com>,
	"Steven L. Zook" <SLZook@Qualstar.com>,
	gcc@gcc.gnu.org
Subject: Re: Nested Functions in C++
Date: Sun, 24 Oct 2004 03:29:00 -0000	[thread overview]
Message-ID: <417A4537.7050206@gnat.com> (raw)
In-Reply-To: <16762.15479.761874.794593@cuddles.cambridge.redhat.com>

Andrew Haley wrote:
> Mark Mitchell writes:

>  > Technically, it's only work.  But, the C++ maintainers (myself included) 
>  > will probably not be keen on accepting such a patch.  We're generally of 
>  > the opinion that adding extensions to C++ is a mistake, unless they go 
>  > through the ISO standardization process first.
> 
> I've always been baffled by this line of reasoning.  The TC is not in
> the business of language design AFAIK, and surely they shouldn't be
> standardizing features that haven't been implemented by anyone.
> 
> So, if we don't implement proposed language extensions people who want
> to experiment will probably be forced to use proprietary compilers.
> 
> And no, this isn't a call for a free-for-all.  But some extensions are
> so useful that we should seriously consider them before the TC has
> decided to standardize them.

I agree with Andrew here, I don't think it is necessary to wait
for the standardization process to be completed before new features
are implemented. At the same time, I don't think you want to go wild
implementing fun new features.

In the GNAT arena as an example, there are a number of language
proposals for "Ada 2005" which is the new version of the language
expected to be finally approved in 2005. We are actively implementing
features that have been tentatively approved by the first
stage of the process. This means that many of these features
are available today in GNAT and can be used more than a year
before they are officially standardized. People using these
features are certainly warned that things might change before
the final standard (the removal of WITH TYPE was a good example),
but on the other hand, the Ada community can experiment with the
use of these features now, and we think that kind of input will
be very helpful in making sure that the final features that are
approved will be done right. We certainly don't want too much
churning around, so we try to implement only things that we think
are pretty sure to be approved (we participate actively in the
standardization process of course).


      parent reply	other threads:[~2004-10-23 11:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-22  4:11 Steven L. Zook
2004-10-22 19:04 ` Mark Mitchell
2004-10-23  0:43   ` Joe Buck
2004-10-23 15:10     ` Gabriel Dos Reis
2004-10-23 16:17       ` Joe Buck
2004-10-23 13:52   ` Gabriel Dos Reis
2004-10-23 16:54   ` Andrew Haley
2004-10-23 16:58     ` Steven Bosscher
2004-10-24 11:35       ` Andrew Haley
2004-10-24 12:01         ` Robert Dewar
2004-10-24 18:05           ` Gabriel Dos Reis
2004-10-24 18:08             ` Robert Dewar
2004-10-24 18:51               ` Gabriel Dos Reis
2004-10-24  3:29     ` Robert Dewar [this message]

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=417A4537.7050206@gnat.com \
    --to=dewar@gnat.com \
    --cc=SLZook@Qualstar.com \
    --cc=aph@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    /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).