<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 13, 2014 at 5:44 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Jan 13, 2014 at 8:39 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>

> On Mon, Jan 13, 2014 at 5:31 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, Jan 13, 2014 at 8:20 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> 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<br>
>> >> > <<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<br>
>> >> >> > existing<br>
>> >> >> > clang<br>
>> >> >> > deployments, because _has_attribute() currently emits a parse<br>
>> >> >> > 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>
>> >> >> "<br>
>> >> >> magic" by expanding the non-function-like form into a value that<br>
>> >> >> 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<br>
>> > 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>
>> 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?<br>
><br>
><br>
> It's a possibility. It could be that a new name is a better approach, but<br>
> both directions seem to be feasible.<br>
<br>
</div></div>I'll ponder; I rather like keeping the existing name.</blockquote><div><br></div><div>By the same argument, it's possible to add extra arguments to __has_attribute, if we have a __has_feature check for the new syntax.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>><br>
>> > Also, supporting arguments in the attributes is useful in some cases --<br>
>> > 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>
>> 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?<br>
><br>
><br>
> They represent themselves. Suppose we added support for a format attribute<br>
> with negative indices, or with three indices, or something -- this syntax<br>
> would allow the user to determine if that syntax is available.<br>
><br>
>> Can they be elided? If so, can we come up with<br>
>> declarative rules as to when they can be elided?<br>
><br>
><br>
> If you could omit them, how would you tell whether an attribute could be<br>
> used without arguments?<br>
><br>
> Again, I'm not saying we should go in this direction, but I don't think we<br>
> should dismiss it without consideration -- we probably don't want to find we<br>
> need a third form of __has_attribute later =)<br>
<br>
</div>That's one of the reasons Alp's suggestion for forwards compatibility<br>
is so nice -- if implemented properly, we could add parameter support<br>
at a later date (presuming we stick with the attribute syntax style<br>
approach).<br>
<br>
I'd like to avoid attempting to preprocess parameters for this patch,<br>
but had intended to leave the door open for the future. So it wasn't<br>
entirely without consideration. ;-)</blockquote><div><br></div><div>=) OK then!</div></div></div></div>