<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'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'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"><<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've attached the work I'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'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'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>