Ok, this is what I have so far

If a keyword is used, a colon must precede it.

[=]a, b : mutable { ... }

Also, no default arguments will be allowed as they open the gates for
literally all symbols an will make parsing very hard.

So, in the end arguments will be bound b/w

[] or <>

and

{ or -> *ret* or : *keyword*

Thoughts?


On Fri, Feb 28, 2020 at 11:17 AM Михаил Найденов <mihailnajdenov_at_[hidden]>
wrote:

>
>
> On Thu, Feb 27, 2020 at 7:06 PM Arthur O'Dwyer via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Thu, Feb 27, 2020 at 5:19 AM Михаил Найденов via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Hello, I am aware of the multiple failed attempts at "abbreviated
>>> lambda", summarized here
>>> <https://brevzin.github.io/c++/2020/01/15/abbrev-lambdas/>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.
>>>
>>
>
>>
>> Okay, I buy that. At least I don't find it unbelievable. Divide and
>> conquer: to shorten the whole lambda, first shorten the parameter list, and
>> also, orthogonally, shorten the function body.
>> However, in your message you showed only the first part (shortening the
>> parameter list). Your proposal can't be "We need to do two things; here's
>> how to do one of them; the other one is harder so I didn't solve it." You
>> need to present a complete solution. Otherwise, we get halfway down the
>> road you selected and we discover that it's a dead end.
>>
>
> The idea is, even if we can't get the forwarding body ever, not having to
> specify the types is huge win on its own as it is only C++ that requires
> them in lambda expressions (for no good reason)
>
>
>
>>
>>
>>> 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
>>>
>>
>> The other problem is, what is the type of `a`? Should it be considered
>> the same as `auto a`? Same as `auto&& a`?
>> There are good reasons to dismiss `auto a` for non-trivially-copyable
>> types and therefore pick `auto&& a`.
>>
>>
>>> *Proposal*
>>>
>>> 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 { ... }
>>>
>>
>
>> Or `constexpr` or `noexcept` or any of the other things that can go in
>> the post-parameter-list spot, right?
>>
>> Think about how this syntax will interact with C++20's explicit template
>> parameters, i.e. how would you express []<class T>(T::type a){} in terse
>> notation? "You can't use the terse notation for that" is an acceptable
>> answer, but you should be explicit about it.
>>
>
> I think one should be able to mix both
>
> []<class T>T::type a, b {}
>
> We will have again considerable gains here as well, because the explicit
> tml arg syntax is already big enough.
>
>
>> Think about how this syntax interacts with contextual keywords and
>> similar silliness, and whether you care. (You probably don't.) For example,
>> []final{} becomes a valid expression, as does []mutable{} — the former
>> is a lambda of one argument, and the latter is a lambda of zero arguments.
>>
>
> This is a good point. BTW what happen with "Down with ()!"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1102r0.html ?
>
> In any case, it seems we will need a way to terminate the list,
> independent of the keyword at the end. Otherwise we are not future proof
>
> class a{};
> []a b { ... }
>
> `b`, becomes a contextual keyword and boom.
>
>
>> template<class T> void foo();
>> template<class T> void bar() { foo(T{}); foo([]T{}); } // both are
>>
>
>>
>> I see two big reasons to reject this proposal:
>> (1) It's incomplete. By itself it doesn't solve the problem, and you
>> haven't shown that going down this road will lead us to the other half of
>> the solution.
>> (2) It shuts doors we are already interested in. Specifically, the syntax
>> []foo is frequently mentioned as a way of "lifting" an overload set into a
>> lambda — that is, []foo should mean roughly [](auto&&... as)
>> noexcept(noexcept(foo(FWD(as)...))) -> decltype(foo(FWD(as)...)) { return
>> foo(FWD(as)...) }.
>>
>> std::transform(first, last, []std::toupper); // OK
>>
>> If you want to take the syntax []foo {}, you'd better be grabbing it for
>> something that will be *better* than lifting. I don't think you are.
>>
>
> The lifting (using this syntax) was already presented and rejected no?
>
> In any case, lifting will be much less of an issue with terse lambdas for
> the incidental cases, and with the new inline global objects for the common
> cases
> Ultimately, you dont want to generate a new wrapper locally every time
>
> std::transform(first, last, std::toupper_obj);
>
> std::toupper_obj being a global wrapper, used by anyone
>
>
>> –Arthur
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>