djasper added a comment.

In, @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.

  rC Clang

cfe-commits mailing list

Reply via email to