RFC 2229

[nikomatsakis]

Summary

RFC 2229 modifies closures so that they do not capture entire variables but instead more precise paths.

Info

• Lead: nikomatsakis
• Lang-team liaison: nikomatsakis
• Charter: to implement RFC 2229
• Repository rust-lang/project-rfc-2229
• Zulip stream #t-compiler/wg-rfc-2229

What is this issue?

This issue represents an active project group. It is meant to be used for
the group to post updates to the lang team (and others) in a lightweight
fashion. Please do not use the comments here for discussion, that should be kept
in the Zulip stream (discussion comments here will be marked as off-topic).

[arora-aman]

There are some more relaxations to closures that can be made as side effects of work being done for 2229, proposed details can be found here: rust-lang/project-rfc-2229#16

[nikomatsakis]

Update 2020-10-26:

Uncovered a few interesting things this far. For example, this changes behavior:

let c = || {
    let _ = x;  // today: borrows `x`
};

In the new edition, using the new RFC, x would not be captured.

[arora-aman]

• Feature mostly works and is avaiable under #![feature(capture_disjoint_fields)]
• We have handled all edge cases we are aware of including patterns, FRU syntax, references in move closures, handling unsafe
• Migration lint for drop reordering is supported under #[deny(disjoint_capture_drop_reorder)] and is supported using rust fix.
• On going work to support migration for auto-traits, and diagnostics

[arora-aman]

The workgroup's focus over the last month has been diagnostics, migrations and getting closer to the edition 21 release.

1. Diangostics

• Overall improvement to closure diagnostics: we now point to part of the source code responsible for the capture kind associated with the error message.
• eg:

let mut p = Point { x: 1, y: 2 };
let y = &p.y; 

let mut c = || {  								   
    println!("{:?}", p);  								
    let x = &mut p.x;
};

c(); 
println!("{}", y);

Ouput before change:

Output ater change (available on rust nightly):

---

2. Migrations

• We can now detect if the closure after enabling RFC 2229 will not meet Clone or any of the auto trait bounds and can provide migrations for it. These migrations are supported via rustfix as well.
• We can annote drop implementations with #[rustc_insignificant_dtor] to avoid migrating in scenarios where drop order doesn't affect semantics of the program. We intend to use this attribute to annotate the stdlib to mark certain type as safe to be Drop reorded. eg: when a string gets dropped it would not affect the behavior of rest of the program.

---

3. Closure Size

• We wrote an initial implementation for printing out the closure size before and after the feature. The implementation is somewhat incomplete, but was good enough for us to get some data on cargo and stdlib.

Cargo and all depensices size data: https://docs.google.com/spreadsheets/d/1Irsj5O7HPPfomWat2jPTPdx_KPlsyYo5kRuQpNNuwsQ/edit?usp=sharing

[arora-aman]

• Lots of progress squelching small bugs in the implementation
• It's now enabled by default in edition 2021
• We are working to add material to the reference and to create a concise, formal definition of what gets captured and what doesn't (separate from the code)
• We tested the size of closures and discovered one critical optimization. (Data that was collected is linked here: 2229: Reduce the size of closures with capture_disjoint_fields rust#86701 (comment))
• After optimization closures appear largely unchanged, but we added a useful flag (-Zprofile-closures) to measure and are going to ask people to do so

[nikomatsakis]

Stabilized!