Formal proposal for closures

[monte]

Good day, everyone.

I trust all is well.

I would like to ask if we could get a formal proposal drawn up for closures.
It seems that there is currently no formal proposal for closures.

Please also note the following forum post:
When should thin or unified be used on closures?

My working assumption is that closures are a work-in-progress, hence the lack of documentation.
But, similarly, struct extensions are a work-in-progress and has a formal proposal.

Any concrete indication of the feature’s state / progress would be appreciated.

• What are the current problems / blockers being worked on?
• What direction is the team working towards? (The kind of information usually detailed in a proposal)
• Are closures expected to be part of v1.0, or is this a post-1.0 feature?

[Caroline (Caroline Frasca)]

Hi @monte,

Apologies for the slow response here! Just wanted to make sure you’ve seen @Steffi’s recent post on the updates to closures:

Mojo Closures 2026

Mojo Closures Before this release, Mojo has had several flavors of closures: Legacy capturing[_] closures — @parameter functions passed only as compile-time type parameters, with implicit captures (and @__copy_capture to opt into copy semantics). Escaping closures — escaping functions emitted as heap-allocated struct instances and passed as runtime values. Unified closures — declared with the unified keyword, with explicit capture lists (e.g. unified {var x, mut y}), and passed as both a type …

[monte]

Hello, @Caroline.

Thank you for the feedback - I appreciate the “closure” on this

I see that the language referance on the git repo has been updated with additional details on closures:
closure-declarations.mdx

Best regards.
Monté.