<div>This looks like a great start.</div><div><br></div><div>1) Clang has separate __has_feature(X) and __has_extension(X) macros. The former determines whether the feature is available as part of the enabled language standard in the current compilation, and the latter determines whether it&#39;s available (possibly as an extension) in the current compilation. The difference is that use of __has_extension(X) features may generate warnings (and, with -Werror or -pedantic-errors, may generate errors).</div>
<div><br></div><div>Which of these is the behavior we want for these feature-test macros? In my experience, __has_feature(X) is what you want when determining whether to use a language feature in normal code, but __has_extension(X) is what you want when determining whether to use a language feature in a system header.</div>
<div><br></div><div>2) At what point will we consider these names stable enough for compiler vendors to start providing them? Are we OK with compilers starting to define these today? (FWIW, I think this is fine.)</div><div>
<br></div><div>3) Can we split a __cpp_decltype_auto out of __cpp_return_type_deduction? These are essentially two separate, orthogonal features, which just happen to have been added in the same paper. There&#39;s a decent chance that Clang 3.3 will ship with the former but not the latter.</div>
<div><br></div><div>4) I agree with Jens that a feature-test macro for __cpp_new_merging is unlikely to add any value.</div><br><div class="gmail_quote">On Thu, May 2, 2013 at 3:33 PM, Nelson, Clark <span dir="ltr">&lt;<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;ve attached the work I&#39;ve done so far towards drafting a feature-testing recommendation for C++14. The prose is just copied from my original paper (N3435), as a sort of place-holder for an introduction. The real work went into the table.<br>

<br>
FYI, part of my idea at this point is to include as much useful information in the table as will fit. Hopefully, the table will eventually become a fairly well-known resource; if so, more people will be exposed to the general idea of standard feature-test macros, and to the specific macro names.<br>

<br>
Let&#39;s see how well the attachment makes it through our reflector.<br>
<br>
(FYI, I may not see any comments on this until Monday. I&#39;m really not ignoring you. :-)<br>
<span class="HOEnZb"><font color="#888888"><br>
Clark<br>
</font></span><br>_______________________________________________<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>
<br></blockquote></div><br>