closures -- how to model them

[nikomatsakis]

We need to decide how to model closures. They have a lot of fun stuff to consider:

• borrow check interactions
• outlives
• etc

[System625]

Hello @nikomatsakis , I would like to attempt this issue, thank you

[nikomatsakis]

@System625 hey! Sorry I closed the PR! I realize that probably came across as discouraging. I'd love to work with you on this though! We should decide the first approach.

[System625]

Hello @nikomatsakis , thank you for the encouraging message! I noticed that you've merged the PR that was blocking the issue, perhaps we can continue the discussion the approach?

[nikomatsakis]

OK, let me try to think this through. I want to focus first on the "easy case" of closures, which are the case where they don't actually use any variables from the surrounding scope.

I think we need to---

• Extend the set of types with a "closure" expression. There's an interesting question of how "nominal" closures can be. In rustc... they are both nominal and not nominal, I realize.
• Extend the Expr with a "closure". I would expect a fully annotated closure signature. This is interesting because it touches on how to do higher-ranked things.
• Extend the type checker to type-check closures properly.

Actually the more I think about this, the more I think we should mark this as blocked -- there's foundational work to be done (at minimum, the higher-ranked treatment).

[System625]

OK no problem, I guess it will be moved to the backlogs till you open issues for the foundational work, cool!