Typz added a comment.
> 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 think we have a really diverging opinion on this. From my experience, people
will mostly accept the output of the formatter without question : therefore I
think we should strive to have the formatter format things as "correctly" as
possible. And looking at the existing options and various complex formatting
algorithms implemented I think this reasoning has been applied to some extent
:-)
So I personnally would be willing to add some code/options even for such kind
of corner cases; but then I am not the one maintaining the clang-format project.
> 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.
Any change will still require a new flag somewhere, since the currently
implemented behavior is :
1- the documented way to format in Google style
2- the expected format in LLVM style, according to the clang-format unit test
It should thus probably not be changed.
> IMO, for the same reason, this specific issue will not become part of the
> style guide of projects.
I definitely agree on this, but it is actually part of some styles (e.g.
Google's)
> 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).
I am fine with that formatting (though I did not implement it since it requires
tweaking the code in more places, instead of essentially modifying a single
function like I did).
Repository:
rC Clang
https://reviews.llvm.org/D43183
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
