closures proposal

[bindsdev]

Basis

Currently, it seems like first-class/higher-order functions are supported, looking at the apply.carbon example in explorer/testdata/generic_function. I believe that since this support exists, there should also be support for closures. Implementation of this could constitute interfaces made for closures, much like how __Fn seems like it is a function pointer. Closures would potentially be able to capture variables in its environment in multiple different ways. This would constitute the need for a few interfaces that correspond to each way a closure could capture items in its environment.

The Interfaces

Closures can capture items from their environment in a variety of ways. It could move them, take them by reference, etc.
Interfaces corresponding to these different ways of capturing could potentially be:

MoveClosure: takes ownership of anything it captures. The types of the variables captured must implement the Movable interface (if this is the interface that signifies something can be moved).
RefClosure: takes anything it captures in its environment by reference.

Potentially interesting, but maybe not as plausible, abstractions could be:

DerefClosure: dereferences anything it captures. The items it captures must be references.
PointerClosure: takes pointers to anything it captures in its environment. (T*)

Most of these interfaces would also have to be thread safe so they could be usable in code that utilizes threading and concurrency.

Inspiration

This implementation of closures is heavily inspired by how Rust deals with closures, using the Fn, FnOnce, and FnMut traits.

What needs to be resolved before implementation?

• Lifetime and Move Semantics
• Co-routines
• Concurrency
• Safety

What needs to be considered?

• Syntactically, how would a closure look like?
• How would each version of a closure interface be related to or interact with each other? Would they all be a sub interface of one interface? Would one closure interface imply another (like super traits in Rust)?
• Would there be any compile-time or runtime cost for closures?

[OlaFosheimGrostad]

• Would there be any compile-time or runtime cost for closures?

Depends. C++ lambda-closures aren't really closures in the traditional meaning, they are syntax sugar for regular classes (function objects). I suspect C++ coroutines are closer, and concurrency requirements make closures expensive as they usually have to be put on the heap.

High level languages often implement all state as closures. Simula did that I believe. They don't use the system stack and put everything on a garbage collected heap: objects, coroutines, activation-records for function calls, everything using the same closure-like construct internally… This is extremely uniform and flexible, but more difficult get good performance out of. I have heard that Sun gave up on this idea for Java, for performance reasons.

[YagaoDirac]

I'm not very sure that, python, js, lua all have only closure, they don't have real function. Closure and function maybe different for these languages. But I think functor is good enough for a c++ level language.

[bindsdev]

• Would there be any compile-time or runtime cost for closures?

Depends. C++ lambda-closures aren't really closures in the traditional meaning, they are syntax sugar for regular classes (function objects). I suspect C++ coroutines are closer, and concurrency requirements make closures expensive as they usually have to be put on the heap.

High level languages often implement all state as closures. Simula did that I believe. They don't use the system stack and put everything on a garbage collected heap: objects, coroutines, activation-records for function calls, everything using the same closure-like construct internally… This is extremely uniform and flexible, but more difficult get good performance out of. I have heard that Sun gave up on this idea for Java, for performance reasons.

Yeah. Performance would probably be the most important and crucial consideration towards the implementation of this.

[chandlerc]

This is more of a discussion about a potential closure proposal. I'm moving it to our discussion forums rather than being an issue. Also might be good for @JamesJCode to chime in here as I think he's been exploring lambdas currently.

[JamesJCode]

Thanks for the heads-up! Yes, we've been actively discussing lambdas and closures over on the #lambdas channel on Discord. This has thrown up a whole load of related language linkages, behavioural choices, and syntax decisions. There are also some really interesting consequences of Carbon's enforced rvalue / lvalue semantics, which are seen elsewhere but are exposed in new ways when thinking about lambdas and closures.

We're now in a place where we have three competing models for how closures / captures should work. I'm just working on writing them up in a manner that aids comparison, as at the moment they are spread right through the Discord chat.

Please do drop in to take a look - This was last night's write-up of where we are, but please note things have moved on considerably since even then; it's been quite fast-moving! https://discord.com/channels/655572317891461132/999638000126394370/1002612319102177341

[bindsdev]

Great. I will make sure to check that out right now.

[asb]

We're now in a place where we have three competing models for how closures / captures should work. I'm just working on writing them up in a manner that aids comparison, as at the moment they are spread right through the Discord chat.

@JamesJCode apologies if I missed this write-up elsewhere, and also if bumping an old thread is bad practice here (vs creating a new one). I'm wondering if the options for closures + captures ever did get written up? Thanks in advance.

[chandlerc]

Not sure if James is still able to be active, but there is fresh discussion on lambdas in the #lambdas channel of Discord if you'd like to ask there?