<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 9, 2014 at 3:39 PM, Stephen Kelly <span dir="ltr">&lt;<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Nelson, Clark wrote:<br>
<br>
&gt;&gt; &gt; Would it be fair to restate your questions as, why are we<br>
&gt;&gt; recommending<br>
&gt;&gt; &gt; something like __has_attribute when we didn&#39;t recommend<br>
&gt;&gt; __has_feature?<br>
&gt;<br>
&gt; I was actually hoping someone would provide an answer to that question.<br>
<br>
</div>Can we ask the person who proposed it?</blockquote><div><br></div><div>I don&#39;t see any solid reasons to avoid a function-like attribute detection macro. Yes, it requires preprocessor support beyond just defining some extra macros, but does that actually matter to any implementor? We already crossed that bridge with __has_include.</div>

<div><br></div><div>As for __has_cpp_attribute, it provides a way to query non-standard attributes as well as standard ones. Sure, we could define an encoding such that an implementation can define __has_cpp_attribute_&lt;attribute-scope-token&gt;_&lt;attribute=name&gt; or similar, but...</div>

<div><br></div><div> 1) That&#39;s a *lot* of macros. We might be able to get away with the cost of the number of macros that SG10 is currently proposing, but I would be *seriously* concerned about a measurable performance cost (on compiling an empty file, which is not actually an irrelevant concern) of predefining hundreds of __has_attribute macros.</div>

<div><br></div><div> 2) Either of those identifiers could contain underscores, and there is no other separator character that works.</div><div><br></div><div>[3) It&#39;s ugly.]</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>
&gt; I myself am opposed -- weakly -- to the __has_attribute syntax, or some<br>
&gt; variation thereof, for all the reasons we didn&#39;t go with __has_feature in<br>
&gt; the first place, as I explained a couple of weeks ago.<br>
<br>
</div>I favor consistency between the feature test and the attribute test.<br></blockquote><div><br></div><div>I agree that there&#39;s value in the two being consistent. But I think there are other concerns that we should be weighing.</div>
<div><br></div><div>I&#39;m still not entirely sold on the argument that took us away from something like __has_feature(x), but that ship has sailed. The argument there that holds most weight with me is that features are sometimes provided by the library instead of the language, and it&#39;s easy to portably define __cpp_whatever but not so easy to portably extend a magical __has_feature syntax.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I weakly favor __has_foo() for these reasons:<br>
<br>
1) For creating the consistency (at least from the users point of view) of<br>
all such tests now and in the future being __has_foo().<br>
<br>
For example, __has_builtin(is_final) might solve the problem here:<br>
<br>
 <a href="http://www.open-std.org/pipermail/features/2014-May/000176.html" target="_blank">http://www.open-std.org/pipermail/features/2014-May/000176.html</a><br>
<br>
See<br>
<br>
 <a href="http://thread.gmane.org/gmane.comp.compilers.clang.devel/34252" target="_blank">http://thread.gmane.org/gmane.comp.compilers.clang.devel/34252</a><br>
<br>
<br>
2) For making it harder for users to make mistakes such as<br>
<br>
#ifdef __cpp_foo<br>
#endif<br>
<br>
when they meant<br>
<br>
#if __cpp_foo<br>
#endif<br>
<br>
or<br>
<br>
#if __cpp_foo &gt; 201404<br>
#endif<br>
<br>
or<br>
<br>
#if __cpp_foo &gt;= 201404<br>
#endif<br>
<br>
<br>
<br>
I think __cpp_foo is fine because it might be easier to implement. However,<br>
I would request consistent prefixes/namespacing to allow for growth in the<br>
classes of tests recommended (eg builtins):<br>
<br>
 <a href="http://thread.gmane.org/gmane.comp.lang.c++.isocpp.features/11" target="_blank">http://thread.gmane.org/gmane.comp.lang.c++.isocpp.features/11</a><br>
<br>
Thanks,<br>
<br>
Steve.<br>
<div><div><br>
<br>
_______________________________________________<br>
Features mailing list<br>
<a href="mailto:Features@isocpp.open-std.org" target="_blank">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></div></div></blockquote></div></div></div>