On Fri, May 3, 2013 at 10:26 PM, Jens Maurer <span dir="ltr"><<a href="mailto:Jens.Maurer@gmx.net" target="_blank">Jens.Maurer@gmx.net</a>></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>
> This looks like a great start.<br>
><br>
> 1) Clang has separate __has_feature(X) and __has_extension(X) macros.<br>
> The former determines whether the feature is available as part of the<br>
> enabled language standard in the current compilation, and the latter<br>
> determines whether it's available (possibly as an extension) in the<br>
> current compilation. The difference is that use of __has_extension(X)<br>
> features may generate warnings (and, with -Werror or<br>
> -pedantic-errors, may generate errors).<br>
><br>
> Which of these is the behavior we want for these feature-test macros?<br>
> In my experience, __has_feature(X) is what you want when determining<br>
> whether to use a language feature in normal code, but<br>
> __has_extension(X) is what you want when determining whether to use a<br>
> 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'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'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">
> 2) At what point will we consider these names stable enough for<br>
> compiler vendors to start providing them? Are we OK with compilers<br>
> 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's<br>
just Clark's ideas, not coordinated with anyone. I'd like to see<br>
at least an N-numbered paper and possibly a "letter ballot"<br>
equivalent [i.e. a table of interested people with yes/no/abstain]<br>
recorded on some wiki page, or a teleconference, to "ok" a given<br>
version of the list. Remember that we can't change the names<br>
going forward.<br>
<div class="im"><br>
> 3) Can we split a __cpp_decltype_auto out of<br>
> __cpp_return_type_deduction? These are essentially two separate,<br>
> orthogonal features, which just happen to have been added in the same<br>
> paper.<br>
<br>
</div>Sounds like a good idea.<br>
<div class="im"><br>
> 4) I agree with Jens that a feature-test macro for __cpp_new_merging<br>
> 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>