On 24 March 2015 at 18:30, Nelson, Clark <[email protected]> wrote:
> > Should TSes use the macro spelling pattern > > > > __cpp_experimental_whatever > > > > or > > > > __cpp_whatever > > > > assuming that the value of the macro will change anyway when > > a feature > > moves from TS land to the standard proper? > > The question is, when a feature from a TS is incorporated into the > standard, > will it be changed enough to effectively make it a different feature from > what was in the TS? For libraries, I'd say yes. At a minimum, it will be in a different namespace (std vs std::experimental), so it is effectively a different type, even if we don't touch the interface at all (unless inline namespaces solve the problem for unchanging interfaces; I don't know them well enough). Is your principal concern about the TM TS? Is there an expectation that a > feature-test macro will be added to it before it is finalized? > My concern is the Lib Fundamentals TS. > It would be more consistent with what SG10 recommends for library TS > features > to be indicated by a macro named __cpp_lib_experimental_whatever. > That addresses my concern. > For library features, LWG wants to retain the option of changing the > interface when a feature is incorporated into the standard. To do that, > they > are taking the radical position of forcing the feature as defined in the TS > to be different from will eventually be incorporated into the standard, by > putting it into a different namespace. > > I understand why they're doing that, but the philosophy is 180 degrees > different from that of SG10. We're trying to make transitions as smooth as > possible; they are intentionally building a speed bump at the transition. > That's not to say that what they are doing is wrong, but it does mean that > there is inherently tension and conflict of purpose between SG10 and LWG. > > All I can say about "experimental" language features is that it sure would > be nice if we could get them right in the TS, so that, when (or if) they > are > incorporated into the standard, they don't have to be changed enough to be > considered a different feature. > All good observations. -- Nevin ":-)" Liber <mailto:[email protected]> (847) 691-1404
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
