[cfe-commits] [PATCH] Initial version of formatting library

[Daniel Jasper]

Yes. And those cases are fairly easy to handle by splitting the
statement into multiple unwrapped lines, i.e. in your example:
1: std::for_each(v.begin(), v.end(), [](int x) {
2: func(x);
3: });

It gets problematic if there are further parameters to for_each after
the lambda, i.e. in unwrapped line #3, and their indentation depends
on decisions made in #1. And that's something we should keep in mind,
but we should not get lost by trying to cope with every rare syntax
construct upfront. There are definitely ways to solve that.

On Fri, Nov 16, 2012 at 1:32 PM, David Blaikie <dblaikie at gmail.com> wrote:
> On Fri, Nov 16, 2012 at 1:27 PM, Daniel Jasper <djasper at google.com> wrote:
>>
>>   I am not entirely sure how that would be broken into unwrapped lines. We can:
>>   - Carry state from on unwrapped line into another
>>   - Put all of it into a single unwrapped line (and somehow reuse the level parsing?)
>>   - Do less then ideal formatting
>>
>>   However, I don't even know what the correct formatting of such lambdas in call expressions would be (especially if you would have additional parameters afterwards, etc.), so I would not want to write any precise assumptions into comments right now.
>
> While, as you say, addressing this just now might be premature (you've
> probably got some more common/basic scenarios to address first) I'll
> throw in my 2c of experience with writing lambda-heavy code. Quite
> often the lambdas are written as the body of a construct, such as:
>
> std::for_each(v.begin(), v.end(), [](int x) {
>   func(x);
> });
>
> Some examples in one of Herb Sutter's presentations on lambdas:
> http://www.nwcpp.org/images/stories/lambda.pdf