An abbreviated lambda proposal can't be considered complete without the ability to omit the "return" keyword.

Please see this review of Rust lambda syntax for C++:

1. Today
[](const auto& a, const auto& b) { return a < b; }
2. Yours
[] a, b { return a < b; }
3. Mine
|a, b| a < b

27.02.2020, 13:19 Михаил Найденов via Std-Proposals <
Hello, I am aware of the multiple failed attempts at "abbreviated lambda", summarized here recently. Nevertheless, this feature seems to be too important to abandon and I wanted to share some thoughts I have on the subject.

Ultimately, as far as "terseness" (alone) goes, it is the function argument that are the biggest culprit
[](const auto& a, const auto& b) { return a < b; }

As you can see, if we aim to improve verbosity alone, we should look no further then the params 

With that in mind, I believe we can split the "abbreviated lambda" goal in two tasks - one  for the params and one for the body, assuming the one, regarding the body will be harder because more issues must be solved. 

The only issue, outlined in the blog regarding params is the double parsing - the fact the compiler has to parse until => (if any) to know, if it deals with abbr. params .  
[](a) => ;   //< arg
[](a){};     //< no arg, just void(a) signature


Allow lambda arguments to be declared without parentheses.
A single item introduces an argument with that name.

[]a,b { return a < b; }

This way the parser will immediately know with type of param list it deals with.

It will be possible to add a type as well

[]a, auto b { return a < b; } 

The argument list is bound b/w [] and { or mutable or ->

[]{ ... } 
[]a, b { ... } 
[]a, b -> R { ... } 
[=]a, b mutable { ... } 

My question is
Does anyone see any fatal implementation issues, before I go ahead and write a formal proposal. 

Thank You
Std-Proposals mailing list