<div class="gmail_quote">On Sat, Apr 21, 2012 at 7:48 PM, Jordy Rose <span dir="ltr"><<a href="mailto:jediknil@belkadan.com" target="_blank">jediknil@belkadan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br>
On Apr 21, 2012, at 20:40, Chandler Carruth wrote:<br>
<br>
> On Sat, Apr 21, 2012 at 5:10 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
>> On Sat, Apr 21, 2012 at 4:54 PM, Joe Groff <<a href="mailto:arcata@gmail.com" target="_blank">arcata@gmail.com</a>> wrote:<br>
</div><div>>>> For future-proofing's sake, does the standard provide any guidance for<br>
>>> naming nonstandardized attributes? Should the attribute be named<br>
>>> something like 'clang::fallthrough' instead of just 'fallthrough', in<br>
>>> case a future standard or other implementations provide for a similar<br>
>>> attribute with different behavior?<br>
>>><br>
>> Yes, I think so. The attribute namespace mechanism was designed to allow such vendor extensions without creating problems for future standardization.<br>
>><br>
> I would find this extremely unfortunate. The fallthrough check doesn't seem likely at all to be a vendor-specific extension. I can't imagine any possible standardized meaning for the attribute other than the use being proposed here. Forcing users to type 'clang::' in each place seems to reduce the clarity and readability of the construct with no real benefit. Is this really necessary? Can we not add a top-level attribute when it makes sense?</div>
</blockquote><div><br></div><div>This is uncharted territory. However, I should point out that neither g++-4.7.0 nor MSVC even parses (and ignores) C++11 attributes yet (no idea about EDG), so the majority of code which intends to use them will use them via a macro anyway. Consequently, I don't find the clarity argument to be compelling in the short term.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
</div>I'm with Chandler. The namespacing syntax would be useful for something like analyzer_noreturn, but this is something other compiler vendors could implement as well. I know we're supposed to be careful about adding language extensions (should this discussion be on cfe-dev?) but this is hardly a vendor-specific warning.<br>


</blockquote></div><br><div>We have neither obtained, nor even sought, buy-in from other vendors or the standardization committee, so this *is* a vendor-specific attribute in the sense that we are the only vendor who supports it. In my opinion, "other compiler vendors could implement this" isn't a high enough bar; it should be at least "another compiler vendor agrees this is the correct meaning for this attribute and intends to implement it this way". That criterion should be easy enough to meet if we can find someone on the g++ side who is interested in this.</div>