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

[Richard Smith]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120423/0bf986d9/attachment.html>