<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 13, 2014 at 5:31 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 Mon, Jan 13, 2014 at 8:20 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>

> On Sun, Jan 12, 2014 at 4:49 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> 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<br>
>> >> > 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>
>> I kind of like __has_attribute_syntax, truth be told.<br>
><br>
><br>
> Have we given up on using the name __has_attribute too soon? Users of the<br>
> new syntax could write:<br>
><br>
> // Probably already in project's porting header<br>
> #ifndef __has_feature<br>
> #define __has_feature(x) 0<br>
> #endif<br>
><br>
> #if __has_feature(__has_attribute_syntax)<br>
> #define MY_HAS_ATTRIBUTE(...) __has_attribute(__VA_ARGS__)<br>
> #else<br>
> #define MY_HAS_ATTRIBUTE(...) 0<br>
> #endif<br>
><br>
> If it's given a different name, they instead would write something like:<br>
><br>
> #ifdef __has_attribute_syntax<br>
> #define MY_HAS_ATTRIBUTE(...) __has_attribute_syntax(__VA_ARGS__)<br>
> #else<br>
> #define MY_HAS_ATTRIBUTE(...) 0<br>
> #endif<br>
><br>
> So I don't think the change-in-syntax argument holds water.<br>
<br>
</div></div>So are you proposing that we would have a different name for the<br>
purposes of the __has_feature macro? Eg)<br>
__has_feature(__has_attribute_syntax) is 1 for the proposed<br>
functionality, and 0 otherwise?</blockquote><div><br></div><div>It's a possibility. It could be that a new name is a better approach, but both directions seem to be feasible.</div><div> </div><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="im">
> Also, supporting arguments in the attributes is useful in some cases -- it's<br>
> not true that they don't make sense in a feature-checking facility. For<br>
> instance:<br>
><br>
>   __has_attribute( __attribute__((format)) )<br>
><br>
> ... doesn't tell me whether __attribute__((format, gnu_scanf, 1, 2) will<br>
> work (and I'd expect that the format attribute will gain additional<br>
> archetypes in future).<br>
<br>
</div>That's true, but the example also demonstrates why it's kind of<br>
nonsensical. What do the 1, 2 represent for the purposes of<br>
__has_attribute?</blockquote><div><br></div><div>They represent themselves. Suppose we added support for a format attribute with negative indices, or with three indices, or something -- this syntax would allow the user to determine if that syntax is available.<br>
</div><div><br></div><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">Can they be elided? If so, can we come up with<br>

declarative rules as to when they can be elided?</blockquote><div><br></div><div>If you could omit them, how would you tell whether an attribute could be used without arguments?</div><div><br></div><div>Again, I'm not saying we should go in this direction, but I don't think we should dismiss it without consideration -- we probably don't want to find we need a third form of __has_attribute later =)</div>
</div></div></div>