Re: "Experimental" features in releases

[Mark Mitchell <mark at codesourcery dot com>]

Mark Mitchell wrote:

I'm going to send two messages to follow up because I think we've got
two different topics.  This message is about:

> In any case, the broader question is: to what extent should we have
> experimental options in releases, and how should we warn users of their
> experimental nature?

Then, I will send another message about the particular PR in question,
to gcc-patches.

I think there's consensus that experimental features ought to be marked
as such (via documentation, a warning, their option names, or some
such), so that users are aware when they're treading on shaky ground.

However, I think it's also clear that we don't want to keep useful stuff
from going into the compiler, or into releases.  It's a good thing if
users get a chance to try out our latest inventions, both for their sake
and ours, and it certainly seems likely that new features may have more
bugs around the edges, relative to older features.  So, I don't think we
should rush to label everything in sight as experimental, or keep
patches from going in just because they might have a bug or two.

In some cases, we may not know that a feature isn't fully robust when
its added to the compiler, but we might discover that later.  If that
happens, then, presumably, we'll be fixing the feature in future, and
taking it out just to put it back in seems needlessly complicated.  But,
we can warn users that the feature is experimental, if the failures are
common and severe.

I guess we don't quite have consensus on the exact mechanism to use for
the warning, so let's start where I imagine there's no controversy: with
the documentation for the option.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713