On Fri, May 3, 2013 at 10:26 PM, Jens Maurer <span dir="ltr">&lt;<a href="mailto:Jens.Maurer@gmx.net" target="_blank">Jens.Maurer@gmx.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 05/03/2013 11:34 PM, Richard Smith wrote:<br>
&gt; This looks like a great start.<br>
&gt;<br>
&gt; 1) Clang has separate __has_feature(X) and __has_extension(X) macros.<br>
&gt; The former determines whether the feature is available as part of the<br>
&gt; enabled language standard in the current compilation, and the latter<br>
&gt; determines whether it&#39;s available (possibly as an extension) in the<br>
&gt; current compilation. The difference is that use of __has_extension(X)<br>
&gt; features may generate warnings (and, with -Werror or<br>
&gt; -pedantic-errors, may generate errors).<br>
&gt;<br>
&gt; Which of these is the behavior we want for these feature-test macros?<br>
&gt; In my experience, __has_feature(X) is what you want when determining<br>
&gt; whether to use a language feature in normal code, but<br>
&gt; __has_extension(X) is what you want when determining whether to use a<br>
&gt; language feature in a system header.<br>
<br>
</div>I would expect that a system header tried hard to avoid warnings or<br>
errors?<br></blockquote><div><br></div><div>Typically, warnings are suppressed in system headers, so they&#39;re free to (and often do) use any facilities we provide as an extension without worrying about users seeing diagnostics.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why would it use __has_extension(X) with the semantics described<br>
above, then?</blockquote><div><br></div><div>Because it wants to provide extra functionality (for instance, move constructors) even when building in a language which doesn&#39;t officially support that functionality.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
&gt; 2) At what point will we consider these names stable enough for<br>
&gt; compiler vendors to start providing them? Are we OK with compilers<br>
&gt; starting to define these today? (FWIW, I think this is fine.)<br>
<br>
</div>This raises a good point: Versioning of the list.  Currently, it&#39;s<br>
just Clark&#39;s ideas, not coordinated with anyone.  I&#39;d like to see<br>
at least an N-numbered paper and possibly a &quot;letter ballot&quot;<br>
equivalent [i.e. a table of interested people with yes/no/abstain]<br>
recorded on some wiki page, or a teleconference, to &quot;ok&quot; a given<br>
version of the list.  Remember that we can&#39;t change the names<br>
going forward.<br>
<div class="im"><br>
&gt; 3) Can we split a __cpp_decltype_auto out of<br>
&gt; __cpp_return_type_deduction? These are essentially two separate,<br>
&gt; orthogonal features, which just happen to have been added in the same<br>
&gt; paper.<br>
<br>
</div>Sounds like a good idea.<br>
<div class="im"><br>
&gt; 4) I agree with Jens that a feature-test macro for __cpp_new_merging<br>
&gt; is unlikely to add any value.<br>
<br>
</div>Thanks for agreeing with me :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
Jens<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Features mailing list<br>
<a href="mailto:Features@isocpp.open-std.org">Features@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/features" target="_blank">http://www.open-std.org/mailman/listinfo/features</a><br>
</div></div></blockquote></div><br>