djasper added a comment.
In https://reviews.llvm.org/D32478#765642, @Typz wrote:
> Nop, it's formatted like this:
>
> bool a = aaaaaa //
> == bbbb //
> && ccccc;
>
> bool a = aaaaaa //
> == bbbb //
> + ccccc;
>
>
> The current way to format operators is not affected: the indentation is done
> as "usual", then they are unindented by the operator width to keep the
> alignment...
Ah damn. Didn't think about the precedences. What I wanted was for the highest
level to have a one char operator, e.g.
bool a = aaaaaa //
<< bbbb //
| ccccc;
However, you example is also interesting
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;
>
>
> > 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.
I would still be interested in a coding style that recommends this format.
https://reviews.llvm.org/D32478
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
