If lambdas are classes, should you be able to use inheritance?

[OlaFosheimGrostad]

C++ lambdas are regular classes with some syntax sugar, so why are lambdas so much more limited than classes?

For instance, if you have a Transaction class, why not allow a lambda to be a subclass of Transaction?

Note that this isn't all that unusual or unreasonable. As an example, in the programming language BETA (successor to Simula) you can do this:

Transaction: (#
do transaction_begin; inner; transaction_end;
#)

And use inheritance like this:

Action: Transaction (#
do …calculations…;
#)

[JamesJCode]

I'm pulling together the initial lambdas proposal, so would be great to understand this use-case. I'm trying to think through what this looks likes, on the assumption that in "C++ lambdas are regular classes with some syntax sugar" follows through to Carbon. What we're saying in this case is that lambdas could inherit from a base class, while implementing some "Callable" interface. I'd raise the following initlal thoughts (and they are no more than that - for discussion!):

• What if the base class already implements the given Callable interface? - couplling with inherited interface / overload rules
• If we say the thing which makes lambdas special is that they can capture local state, we'd need to think about name collisions. In a contrived case, consider this:

class SmallThing {
  var field: i32 = 2;
}

class ComplexThing {
   var field: i32 = 42;

  fn GetLambda[me: Self] -> auto {
    return lambda : extends SmallThing -> i32 {return me.field;};
  }
}

• Should the lambda capture 42 or 2?

I think the thing from my perspective is: What does allowing lambdas having a base class allow a programmer to accomplish, and how do other languages which allow this construct cope with namespace clashes in captures?

[JamesJCode]

Yes, this is the issue, since I don't know of any other language than BETA (and gBeta) with this feature it also becomes a case of "what would people discover if they could do it"? And the answer to this depends on other language features, which is why innovative language design is sooo hard. But, if lambdas are classes it seems weird that you cannot treat them as such.

It's a delicate balance isn't it, especially if a new construct would add syntax overhead to the language to give benefit which has yet to be discovered / realised.

One good use case ...

In general, inheritance for lambdas would let authors of libraries that use lambdas do something before the lambda is executed, after is executed and also when the lambda is no longer live. So you have 4 "slots" that might be relevant: create/destruct, pre-execution/post-execution.

I'm tending towards @mconst's reflections below; especially if the use-case is to add customisation points. That said, I recognise the fact there may be clever things to be done that we haven't thought of yet. It'll be good to view the talk linked above when the video is released.

• What if the base class already implements the given Callable interface? - couplling with inherited interface / overload rules
  So that depends on the language semantics for overrides, but it might be valuable to make the Callable virtual so that a library can hold a list of super-classes and call the lambda though the virtual table.

We're aiming for lambdas to have zero overhead compared to a regular function call, allowing the compiler to make some pretty hefty optimisations. Clearly calling this through the vtable would impact on this aim. But, if we did follow this model, it could be seen as a thing the user explicitly opts in to in the case that a lambda has a base class.

• If we say the thing which makes lambdas special is that they can capture local state, we'd need to think about name collisions.

You could use super.field for lambda-super and me.super.field, but it would be much better to not allow a capture of me if a lambda is an object. If the lambda is an object me should be the lambda itself?

Maybe one shouldn't capture me with that name, maybe it should be renamed to something else that tells us this is is the calling-context and not the lambda object (if you want the programmer to think of lambdas as objects).

Capturing me in the context of an enclosed scope is something we'd like to do, otherwise it becomes a bit messy to access or mutate the state of the me object itself (see the many discussions about how to capture this in C++ lambdas!). We've got a bit of a working principle that folks should be able to refactor code in to a lambda without the semantics of it changing. If we had me in a lambda declared in a method called something-other-than-me inside the lambda scope, we would violate this. It's not a hard rule, but it feels like a least-surprise goal.

We've discussed something along the lines of $this or $me to represent the lambda itself, to allow recursive calls, so could conceive of a $super or $base like syntax. It's not leaping out to me as great though.

[OlaFosheimGrostad]

It's a delicate balance isn't it, especially if a new construct would add syntax overhead to the language to give benefit which has yet to be discovered / realised.

The benefits are the same as for function objects with inheritance.

I haven't written any BETA code since the 90s, so I don't quite remember the practical consequences, but I do remember that it did lead to other ways of expressing programming ideas. It did provide a different kind of expressiveness than the Simula-family (C++, Java etc). BETA was a more interesting language than Simula because it is a very condensed minimalistic OO design, albeit a bit too uniform in the syntax (some of the same usability consequences as Lisp).

We're aiming for lambdas to have zero overhead compared to a regular function call, allowing the compiler to make some pretty hefty optimisations. Clearly calling this through the vtable would impact on this aim. But, if we did follow this model, it could be seen as a thing the user explicitly opts in to in the case that a lambda has a base class.

There is no overhead if you know the concrete type since the lambda is a final class, and I assume that the superclass could use a discriminating tag instead of a vtable, but I don't know what kind of plans Carbon has in this area.

Unless you want to allow lambdas to be subclassed, of course, but then we have a radical departure from C++.

Capturing me in the context of an enclosed scope is something we'd like to do, otherwise it becomes a bit messy to access or mutate the state of the me object itself (see the many discussions about how to capture this in C++ lambdas!). We've got a bit of a working principle that folks should be able to refactor code in to a lambda without the semantics of it changing. If we had me in a lambda declared in a method called something-other-than-me inside the lambda scope, we would violate this. It's not a hard rule, but it feels like a least-surprise goal.

Yes, C++ programmers would expect this. I guess you could name the lambda-super as base which is consistent with constructor-syntax .base = ….

We've discussed something along the lines of $this or $me to represent the lambda itself, to allow recursive calls, so could conceive of a $super or $base like syntax. It's not leaping out to me as great though.

Since the purpose of a lambda often is to reduce clutter it might be viewed as a bit noisy, but then again, most lambdas won't need this, so maybe it is a decent trade-off. I cannot tell until I have used it, really. It doesn't look too bad, though.

[JamesJCode]

Oh sure on the vtable overhead stuff - I would hope this is fairly trivial to optimise away, or hide in the implementaiton. I'm just thinking out loud about potential issues we should at least think through.

[KateGregory]

I coincidentally recently watched a talk on this subject: C++ Lambda Idioms. According to https://timur.audio/talks , the video for it has not yet been published, but I think it is fair to say that the approach was a bit exotic -- the expectation of the talk was that even experts would learn something from the talk, and many of the techniques in the talk required features from later versions of C++. In C++23, apparently you can use multiple inheritance of lambdas with different signatures and "deducible this" to define a recursive visitor that dispatches to a different lambda based on the type of the node visited.

I also watched that talk. The slides are at https://github.com/CppNorth/CppNorth_2022_Slides/blob/main/Timur%20Doumler%20-%20C%2B%2B%20Lambda%20Idioms.key.pdf

[JamesJCode]

Thanks for the slides link!

[mconst]

I don't think this particular use case requires inheritance at all -- you can just write it as a function:

fn Transaction[Inner: Fn()](inner: Inner) {
    transaction_begin();
    inner();
    transaction_end();
} 

If you have a more complicated situation where you really do need inheritance, I think my preference would be to write that as an actual class with a custom operator() implementation (however we spell that). That gives you the full generality of classes when you want it (not just inheritance, but also additional data members, additional methods, custom impls for arbitrary interfaces, etc.), without needing to find ways to fit all those features into the lambda syntax.

[OlaFosheimGrostad]

The function-approach does not give you a transaction object.

And the second argument is the same as saying that lamdas are superfluous, which is true, but not really helpful.

By this reasoning you can unravel a lot of the design space…