Page MenuHomePhabricator

Please use GitHub pull requests for new patches. Phabricator shutdown timeline

Improve formatting of lambda functions.

Authored by jdennett on Jun 11 2015, 11:00 PM.



Don't let the trailing '*' of a lambda's explicitly-specified return
type be immediately adjacent to the left brace that starts the body
of the lambda.

Before: int *p = []() -> int *{ return nullptr; }();
After: int *p = []() -> int * { return nullptr; }();

Diff Detail

Event Timeline

jdennett updated this revision to Diff 27566.Jun 11 2015, 11:00 PM
jdennett retitled this revision from to Improve formatting of lambda functions..
jdennett updated this object.
jdennett edited the test plan for this revision. (Show Details)
jdennett updated this object.Jun 11 2015, 11:02 PM
jdennett added a reviewer: djasper.
jdennett added a subscriber: Unknown Object (MLST).
djasper edited edge metadata.Jun 12 2015, 12:42 AM

I am not actually sure here. The pro is that it doesn't really belong with the "{". The con is that it looks a lot more like a multiplication. Not so important for "int", but as soon as you have something where you aren't exactly sure that it is a type, this can get confusing.

Also, there is the consistency with "int *f() { return nullptr; }" which we should think about.

All in all, I don't see compelling reasons to do this change yet (but I can be convinced).

All of this just shows that the pointer belongs with the type ;-).

I think we should do this, and I'll try to give a plausibly principled rationale.

We have two uses of {}s that I care about: braced init lists and blocks. For braced init lists, we routinely omit padding spaces around the {}s:

foo({x, y z});
return {{1, 2, 3}};

On the other hand, with every block example I can come up with, we have spaces around the {}s:

if (...) {

int f() {

auto f() {

auto f() -> int {

[] {}, []() {}, []() mutable {}, []() -> int {}

It makes much more sense to me to have a space even in the presence of a pointer (or reference).

Those examples are very selective, though:

someFunction(a, {1, 2, 3});
Debug({ llvm::errs() << "abc\n"; });
SomeIntType b = a * {7};

Ok. To be clear, I don't care strongly at all. If the two of you are convinced this is better, lets just put it in.

How does this relate to "int *f();"? Do we simply not care about that consistency at this point as this is about spacing out braces?

djasper accepted this revision.Jun 12 2015, 3:03 AM
djasper edited edge metadata.

Submitted slightly modified patch as r239600. Thanks!

This revision is now accepted and ready to land.Jun 12 2015, 3:03 AM
djasper closed this revision.Jun 12 2015, 3:03 AM