djasper added a comment.

In https://reviews.llvm.org/D32478#765548, @Typz wrote:

> In https://reviews.llvm.org/D32478#765537, @djasper wrote:
>
> > In all honesty, I think this style isn't thought out well enough. It really 
> > is a special case for only "=" and "return" and even there, it has many 
> > cases where it simply doesn't make sense. And then you have cases like this:
> >
> >   bool = aaaaaa //
> >       == bbbb //
> >       && ccccc;
> >   
> >
> > Where the syntactic structure is lost entirely.
>
>
> It is not lost, extra indent for 'virtual' parenthesis is still there:
>
>   bool a = aaaaaa   //
>             == bbbb //
>         && ccccc;


Ah, right, I was thinking about something else (commas where we don't add extra 
indentation. Anyhow, I don't think what you are writing is what clang-format 
produces. How could it indent relative to the "&&" when placing the "=="? It 
doesn't know how far to unindent at that point, I think.

> 
> 
>> On top of that it has runtime downsides for all clang-format users because 
>> ParenState gets larger and more costly compare. As such, I am against moving 
>> forward with this. Can you remind me again, which coding style suggests this 
>> format?
> 
> This is just a single extra bit (and there are still less than 16 such bits), 
> so it does change the size of ParenState. As for the compare cost, I think it 
> is within reach of the compiler's optimization, but it may indeed have a 
> slight impact.




https://reviews.llvm.org/D32478



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to