djasper added a comment.
In https://reviews.llvm.org/D43183#1006170, @Typz wrote:
> > 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 have no problem with making clang-format format things "correctly" and I am
happy to add code. But I think we are doing the average clang-format user a
disservice if we provide options for every such corner case. Let's settle on
one good-enough behavior and go with that for everything/everyone.
>> 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.
I don't think that's true for the alternative I am suggesting.
>> 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).
As we can implement this without additional flags (it doesn't contradict any
style guide I know of), I think this would be strictly preferable.
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
