> 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? If not, the same macro name should be used; if so, it should be a different macro name. Changing the macro's value is perfectly OK when only a minor tweak is made. 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? > I'd rather that __cpp_experimental_whatever be reserved for > library features that are going into namespace std::experimental. It would be more consistent with what SG10 recommends for library TS features to be indicated by a macro named __cpp_lib_experimental_whatever. > A different spelling for experimental language features is fine by > me. 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. Clark _______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
