<div dir="ltr">On 24 March 2015 at 18:30, Nelson, Clark <span dir="ltr">&lt;<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt;       Should TSes use the macro spelling pattern<br>
&gt;<br>
&gt;         __cpp_experimental_whatever<br>
&gt;<br>
&gt;       or<br>
&gt;<br>
&gt;         __cpp_whatever<br>
&gt;<br>
&gt;       assuming that the value of the macro will change anyway when<br>
&gt; a feature<br>
&gt;       moves from TS land to the standard proper?<br>
<br>
The question is, when a feature from a TS is incorporated into the standard,<br>
will it be changed enough to effectively make it a different feature from<br>
what was in the TS?</blockquote><div><br></div><div>For libraries, I&#39;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&#39;t touch the interface at all (unless inline namespaces solve the problem for unchanging interfaces; I don&#39;t know them well enough).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is your principal concern about the TM TS? Is there an expectation that a<br>
feature-test macro will be added to it before it is finalized?<br></blockquote><div><br></div><div>My concern is the Lib Fundamentals TS.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It would be more consistent with what SG10 recommends for library TS features<br>
to be indicated by a macro named __cpp_lib_experimental_whatever.<br></blockquote><div><br></div><div>That addresses my concern.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For library features, LWG wants to retain the option of changing the<br>
interface when a feature is incorporated into the standard. To do that, they<br>
are taking the radical position of forcing the feature as defined in the TS<br>
to be different from will eventually be incorporated into the standard, by<br>
putting it into a different namespace.<br>
<br>
I understand why they&#39;re doing that, but the philosophy is 180 degrees<br>
different from that of SG10. We&#39;re trying to make transitions as smooth as<br>
possible; they are intentionally building a speed bump at the transition.<br>
That&#39;s not to say that what they are doing is wrong, but it does mean that<br>
there is inherently tension and conflict of purpose between SG10 and LWG.<br>
<br>
All I can say about &quot;experimental&quot; language features is that it sure would<br>
be nice if we could get them right in the TS, so that, when (or if) they are<br>
incorporated into the standard, they don&#39;t have to be changed enough to be<br>
considered a different feature.<br></blockquote><div><br></div><div>All good observations.</div></div>-- <br><div> Nevin &quot;:-)&quot; Liber  &lt;mailto:<a href="mailto:nevin@eviloverlord.com" target="_blank">nevin@eviloverlord.com</a>&gt;  <a href="tel:%28847%29%20691-1404" value="+18476911404" target="_blank">(847) 691-1404</a></div>
</div></div>