Re: C++ PATCH: PR 20599 (1/3)

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On Tue, Sep 19, 2006 at 12:31:26AM +0200, Gabriel Dos Reis wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> [...]
> 
> | It's easy to say "well, we warned the users, it's their problem" --
> | but I don't think that's necessarily how we best convince people to
> | prefer G++ to competing alternatives.
> 
> I strongly agree.
> 
> [...]
> 
> | So, I'm somewhat hesitant to incorporate changes before the standard
> | is sufficiently final. 
> 
> I suspect that is a wise course of action.  I believe development
> on branch is a sufficiently good approach and good compromise, until
> we get near-dry-ink buy-in from the C++ standards committee.

There are certainly risks if we proceed without a finalized standard.

On the other hand, if everyone waits to build implementations until the
committee has finalized the standard, we have the risk that the standard
itself will be low-quality, with standards committees specifying
requirements that have not been successfully implemented anywhere.  Many C
and C++ standard features started as a poorly-specified GNU extension, and
benefit from user experience with those extensions.

Perhaps there is a middle ground: if there is draft standard language for
describing a feature and it appears that the standards committee is
seriously considering it, and there aren't objections on the table or
fights about the form of the feature, then it is a public service if GCC
provides an implementation that allow developers to try out the feature.
The danger is that developers won't understand that it is experimental and
we'll be stuck with pressure to provide backward compatibility, even after
the standards committees have changed the rules.

Maybe, though, we could get the distros to help us out on this one, asking
the major GNU/Linux/BSD distros to have rules against the use of certain
flags in packages that they include.  That way, if future GCCs take out
the experimental feature, distros cannot break, since they didn't allow
it in the first place.

In any case, we shouldn't accept any extension that isn't rigorously specified:
if it isn't in a released standard, it should have a rigorous description
with the same kind of detail that one finds in an official standard.