[cfe-commits] [PATCH] Implicit fall-through between switch labels

[Chandler Carruth]

On Mon, Apr 23, 2012 at 11:47 AM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Sat, Apr 21, 2012 at 7:48 PM, Jordy Rose <jediknil at belkadan.com> wrote:
>
>>
>> On Apr 21, 2012, at 20:40, Chandler Carruth wrote:
>>
>> > On Sat, Apr 21, 2012 at 5:10 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>> >> On Sat, Apr 21, 2012 at 4:54 PM, Joe Groff <arcata at gmail.com> wrote:
>> >>> For future-proofing's sake, does the standard provide any guidance for
>> >>> naming nonstandardized attributes? Should the attribute be named
>> >>> something like 'clang::fallthrough' instead of just 'fallthrough', in
>> >>> case a future standard or other implementations provide for a similar
>> >>> attribute with different behavior?
>> >>>
>> >> Yes, I think so. The attribute namespace mechanism was designed to
>> allow such vendor extensions without creating problems for future
>> standardization.
>> >>
>> > 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?
>>
>
> 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.
>
>
>> 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.
>>
>
> 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.
>

This is a great point. =] I've added some folks more familiar w/ the GCC
community than I am, they can perhaps bring the right people into this
discussion, or point us at the right place to have the discussion.

Until that happens, putting it behind a 'clang::' qualifier seems the
reasonable path forward, and is likely to make any discussion with other
vendors easier as we can document and explain the extension more fully.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120423/eb8fa44e/attachment.html>