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 [EMAIL PROTECTED] (650) 331-3385 x713
