<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jan 12, 2014 at 4:49 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Sun, Jan 12, 2014 at 7:38 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>

><br>
><br>
><br>
> On Sun, Jan 12, 2014 at 6:53 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> > That's good news -- thanks for confirming.<br>
>> ><br>
>> > The feature detection macro itself will still need to have a different<br>
>> > name<br>
>> > (or some other mechanism) so it can be used compatibly with existing<br>
>> > clang<br>
>> > deployments, because _has_attribute() currently emits a parse error<br>
>> > instead<br>
>> > of gracefully returning 0 when passed the new argument syntax:<br>
>> ><br>
>> > tmp/attr2.cpp:1:5: error: builtin feature check macro requires a<br>
>> > parenthesized identifier<br>
>> > #if __has_attribute(__attribute__((weakref)))<br>
>> >     ^<br>
>><br>
>> Good catch. Unfortunately, __has_attribute is really the best<br>
>> identifier for the macro, so I am loathe to let it go.<br>
>><br>
>> Due to the current design of __has_attribute, we can't get away with "<br>
>> magic" by expanding the non-function-like form into a value that could<br>
>> be tested. So we would really have to pick a new name if we are<br>
>> worried about this.<br>
>><br>
>> Suggestions on the name are welcome.<br>
><br>
><br>
> Ok, I'll bite:<br>
><br>
> __has_attribute_written_as([[foo]])<br>
> __has_attribute_syntax([[foo]])<br>
> __has_attribute_spelling([[foo]])<br>
<br>
</div></div>I kind of like __has_attribute_syntax, truth be told.</blockquote><div><br></div><div>Have we given up on using the name __has_attribute too soon? Users of the new syntax could write:</div><div><br></div><div>
// Probably already in project's porting header</div><div>#ifndef __has_feature</div><div>#define __has_feature(x) 0</div><div>#endif</div><div><br></div><div>#if __has_feature(__has_attribute_syntax)</div><div>#define MY_HAS_ATTRIBUTE(...) __has_attribute(__VA_ARGS__)</div>
<div>#else</div><div>#define MY_HAS_ATTRIBUTE(...) 0</div><div>#endif<br></div><div><br></div><div>If it's given a different name, they instead would write something like:</div><div><br></div><div><div>#ifdef __has_attribute_syntax</div>
<div>#define MY_HAS_ATTRIBUTE(...) __has_attribute_syntax(__VA_ARGS__)</div><div>#else</div><div>#define MY_HAS_ATTRIBUTE(...) 0</div><div>#endif<br></div></div><div><br></div><div>So I don't think the change-in-syntax argument holds water.</div>
<div><br></div><div><br></div><div>Also, supporting arguments in the attributes is useful in some cases -- it's not true that they don't make sense in a feature-checking facility. For instance:</div><div><br></div>
<div>  __has_attribute( __attribute__((format)) )</div><div><br></div><div>... doesn't tell me whether __attribute__((format, gnu_scanf, 1, 2) will work (and I'd expect that the format attribute will gain additional archetypes in future).</div>
</div></div></div>