djasper added a comment.
To me none of these options make sense. For the case you are describing, I
agree that the current behavior is not ideal, but neither are any of the
alternatives. However, I think that's fine. We'll just format those cases in a
somewhat weird way and users can either accept that or change their code to not
need it. I don't particularly care which of these options we go with, but I
would be really hesitant to introduce an style flag for it. This is so rare,
that almost no one needs this flag (or should need this flag). Thus, the cost
of the flag (discoverability of flags for users, increased maintenance cost,
etc.) strongly outweigh the benefit. IMO, for the same reason, this specific
issue will not become part of the style guide of projects.
If you want to change something, I'd vote for making clang fall back to this
behavior:
case A:
{
stuff();
}
moreStuff();
break;
}
i.e. not let it put the "{" on the same line as the "case ..." if there is a
trailing statement (other than "break;" maybe).
Repository:
rC Clang
https://reviews.llvm.org/D43183
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
