Named lambdas?

[SebastianTroy]

It occurs to me that naming lambdas might be nice:

// Example
std::transform(x.begin(), x.end(), y.begin(), :(x) -> _ = { x+1; });

// Expression extracted and named for clarity
increment:(x) -> _ = { x+1; }
std::transform(x.begin(), x.end(), y.begin(), increment&);

// Expression named inline for clarity
std::transform(x.begin(), x.end(), y.begin(), increment :(x) -> _ = { x+1; });

The same using the newly proposed terser syntax (#714) :

// Example
std::transform(x.begin(), x.end(), y.begin(), :(x) -> x+1;);

// Expression extracted and named for clarity
increment: (x) -> x + 1;
std::transform(x.begin(), x.end(), y.begin(), increment&);

// Expression named inline for clarity
std::transform(x.begin(), x.end(), y.begin(), increment :(x) -> x+1;);

[JohelEGP]

So, /* increment */ :(x) x + 1?

[SebastianTroy]

fair point

[msadeqhe]

Consider this syntax may be used to support named / keyword arguments in Cpp2:

x: = func(keyarg: (x) x + 1);

keyarg is a named / keyword argument. BTW Cpp2 may never support such feature.

EDIT: But named lambdas as function declarations in your suggestion, is a good idea:

func: (x) x + 1;

[AbhinavK00]

One question I have is what would be the scope of these names. Since they're defined inside an argument list, would they be visible just inside it (that'll probably be useless) or would they be visible in the most enclosing scope where call happens (which I think would be useful, maybe).

[SebastianTroy]

I was envisioning them only having the same scope as their named counterpart, ie an rvalue with no access. I had thought initially it was a nice way to reduce the scope of a named lambda, ie if you wanted to name it but not define it in the same scope as the use. I don't like the idea that it would clash with named parameter specifying. I wanted to name them to give more information to a maintainer of the code base, limiting the name to be the same as the name of the parameter wouldn't achieve anything useful, and having a different name than any of the parameters would be confusing and potentially lead to unexpected compilation errors when refactoring, or worse silent bugs due to successful compilation when refactoring! I do agree that an inline comment really does do what I personally wanted from this suggestion. On 7 October 2023 05:27:26 Abhinav00 ***@***.***> wrote: One question I have is what would be the scope of these names. Since they're defined inside an argument list, would they be visible just inside it (that'll probably be useless) or would they be visible in the most enclosing scope where call happens (which I think would be useful, maybe). — Reply to this email directly, view it on GitHub<#722 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQLK5XLYYDOZHA23QSTX6DK2XAVCNFSM6AAAAAA5RDBEYGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TEMJVGE2DK>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[hsutter]

It occurs to me that naming lambdas might be nice:

Yes, for sure. Adding a name just makes it an ordinary named function -- an unnamed function at expression scope (aka lambda) is just a function that omits the name.

increment:(x) -> _ = { x+1; }

This is a normal function definition, right? I intend to allow those at function scope, I just don't do it right now as a 'temporary alpha limitation.' (Because I would need to lower them to a Cpp1 local lambda, which is easy enough but didn't seem a priority compared to other bugs/features.)

If you write the above at function scope today, you get this diagnostic which tells you how you can write it as... drum roll... actually a named lambda! 😀

error: (temporary alpha limitation) local functions like increment: (/*params*/) = {/*body*/} are not currently supported - write a local variable initialized with an unnamed function like increment := :(/*params*/) = {/*body*/}; instead (add = and ;)

Does the alternative that the diagnostic suggests give you what you're looking for?

[SebastianTroy]

I meant naming lambdas where they can already exist in current cpp2, foo(:(x) x*x); Vs foo(squared:(x) x*x); At the time I believed that it might be useful for code readability. It has been pointed out that foo(/* squared */:(x) x*x); Should achieve what I want with no changes. Also it may clash with named arguments if those are ever supported. Perhaps I ought to close this discussion as I believe my original suggestion has been suitably argued against, and your comment covers the other thing this discussion could conceivably refer to. Thank you and perhaps I'll try and implement local functions so I can contribute something more concrete to this project. On 9 October 2023 14:47:25 Herb Sutter ***@***.***> wrote: increment:(x) -> _ = { x+1; } This is a normal function definition, right? I intend to allow those at function scope, I just don't do it right now as a 'temporary alpha limitation.' If you write the above at function scope today, you get this diagnostic which tells you how you can write it as... drum roll... actually a named lambda! 😀 error: (temporary alpha limitation) local functions like 'increment: (/*params*/) = {/*body*/}' are not currently supported - write a local variable initialized with an unnamed function like 'increment := :(/*params*/) = {/*body*/};' instead (add '=' and ';') — Reply to this email directly, view it on GitHub<#722 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQP2T2F27IEB4GLULQLX6P56VAVCNFSM6AAAAAA5RDBEYGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TEMZQGY4DK>. You are receiving this because you authored the thread.Message ID: ***@***.***>