<div dir="ltr">On Mon, Oct 23, 2017 at 7:33 AM, Aaron Ballman via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Oct 23, 2017 at 9:48 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>> On 10/21/2017 10:14 AM, Aaron Ballman via cfe-commits wrote:<br>
>><br>
>> Attributes come with multiple spelling flavors, but when it comes to<br>
>> adding new attributes that are not present in other compiler tools<br>
>> such as GCC or MSVC, we have done a poor job of being consistent with<br>
>> which spelling flavors we adopt the attributes under. Some of our<br>
>> attributes are specified with only an __attribute__ spelling (about<br>
>> 100), while others are specified with both __attribute__ and<br>
>> [[clang::XXX]] (about 30), and still others are specified as only<br>
>> [[clang::XXX]] attributes (only 1). This puts additional burden on<br>
>> developers to remember which attributes are spelled with what syntax<br>
>> and the various rules surrounding how to write attributes with that<br>
>> spelling.<br>
>><br>
>> I am proposing that we take a more principled approach when adding new<br>
>> attributes so that we provide a better user experience. Specifically,<br>
>> when adding an attribute that other vendors do not support, the<br>
>> attribute should be given an __attribute__ and [[clang::]] spelling<br>
>> unless there's good reason not to. This is not a novel proposal -- GCC<br>
>> supports all of their documented __attribute__ spellings under a<br>
>> [[gnu::XXX]] spelling, and I am proposing we do the same with our<br>
>> vendor namespace.<br>
><br>
> For attributes that both Clang and GCC support, where GCC provides a<br>
> [[gnu::X]] syntax, do you propose that our policy will be to support the<br>
> same?<br>
<br>
</span>Yes; we should use the [[gnu::X]] spelling instead of adding the same<br>
attribute under [[clang::X]] unless we think our semantics need to<br>
significantly differ from GCC's.<br></blockquote><div><br></div><div>This seems like a departure from what you wrote originally, unless you just misspoke or I misinterpreted.</div><div>You originally said, "[New attributes] should be given an __attribute__ and [[clang::]] spelling unless there's good reason not to."  I would 100% agree with that policy, from a user's point of view. It would be awesome to know exactly how an attribute is spelled without having to look it up in the manual.</div><div>But when you used the word "instead" just now, you implied that the policy would be more like "New attributes should be given an __attribute__ and [[clang::]] spelling unless there's good reason not to, <b>or unless Clang is copying work originally done by the GNU project</b>, in which case the new attribute should be given __attribute__ and [[gnu::]] spellings but not a [[clang::]] spelling." Is that really what you meant, or was your original statement closer to what you meant?</div><div><br></div><div>As a user, I would strongly prefer to write all my attributes in a consistent way. If that way has to be __attribute__((foo)), then okay. But in C++11-and-later, it would be nice to write all my attributes as [[clang::foo]], and not have to keep consulting the manual to find out which of [[foo]], [[clang::foo]], and [[gnu::foo]] is the proper spelling for this particular attribute.</div><div><br></div><div>Of course the worst possible outcome would be where [[clang::foo]] and [[gnu::foo]] both exist and have different semantics. I hope that doesn't happen!  But if it has already happened, then it becomes even more important that a user of Clang never need to use the [[gnu::]] spelling for any Clang attribute (because accidentally using [[gnu::]] on the wrong attribute could cause bugs, in the hypothetical case that [[clang::foo]] and [[gnu::foo]] have different semantics).</div><div><br></div><div>Basically, as a user, I would like to see:</div><div>- Attribute names never deliberately collide with other vendors</div><div>- Every attribute supported by Clang is available under __attribute__</div><div>- Every attribute supported by Clang is available under [[clang::]]</div><div>- Any attribute that mimics a GNU feature is available under [[gnu::]] (and also under the two above)</div><div>- Any attribute that mimics an MSVC feature is available under [[msvc::]] (and also under the first two above)</div><div>- Any attribute that mimics a GNU-and-MSVC feature (thus, a feature available on all three platforms) is available under all of [[gnu::]], [[msvc::]], and [[clang::]] (and also under __attribute__)</div><div><br></div><div>Then, as a user, I don't need to care about the historical accident of which project's employees invented a feature first; I can just use the [[xxx::]] prefix corresponding to my primary compiler, and either it will work or it will error out (in which case I'll know that my primary compiler does not support that feature).</div><div><br></div><div>my $.02,</div><div>–Arthur</div></div></div></div>