* Characteristic cognomen: `cromulent_copy_closure_captures` * Calendrical commencement: TBD * CCC (Call Concerning Comments) CC (Conjoinment Call): TBD * Corrosion Casefile: TBD ## Condensation Change closure capture conjecture conventions concerning `Copy`, creating crustacean coder contentment. Concretely, compiler certifies consecutive code: fn callable(c: char) -> impl Fn() -> char { || c } ## Catalyst Rust's closure capture inference rules prefer capturing by reference if possible, and by value only if necessary. However, sometimes it is necessary to force a by-move capture, in order to avoid restricting the closure's lifetime. And even in cases where the behavior would ultimately be the same, by-value capture of small values is often more performant. The `move` keyword forces _all_ captures to be by-move, but this is often insufficiently granular. To force a single capture to be by-move, one can assign the capture to a new local inside the closure: let byref = "Foo".to_string(); let byval = "Bar".to_string(); // Want to write a closure that captures // `byref` by reference, and // `byval` by value let closure = || { let byval = byval; // Force a by-value capture println!("{byref} then {byval}"); }; However, this trick only works for non-`Copy` types! If we replace `String` with `char`, the capture is once again by reference: let byref = 'F'; let byval = 'B'; let closure = || { let byval = byval; // Nope, this is a by-reference capture! println!("{byref} then {byval}"); }; This is due to a special case for Copy in the closure capture rules: > ### Copy values > > Values that implement `Copy` that are moved into the closure are captured with the `ImmBorrow` mode. > > > let x = [0; 1024]; > let c = || { > let y = x; // x captured by ImmBorrow > }; > Because of this special case, it's impossible for a `Copy` closure capture to ever be inferred as by-move. The only way to force a by-move `Copy` closure capture is with the `move` keyword, which requires adapting all the other captures in consequence. This makes common closures less capable and efficient. However, the special case also has benefits, and it would be a breaking change to remove it entirely. Can we find a middle ground? ## Condensed clarification If a closure capture is used exclusively by-move, then the inferred binding mode is always by-move. The following snippet compiles regardless of whether `SomeType: Copy`: use crab_lib::SomeType; fn callable(c: SomeType) -> impl FnOnce() -> SomeType { || c } However, if a closure capture is used both by-move and by-reference within the closure, then the behavior diverges. Non-`Copy` captures are inferred as by-move, but `Copy` captures are inferred as by-reference. The following snippet compiles only if `SomeType` is not `Copy`: use crab_lib::SomeType; fn callable(c: SomeType) -> impl FnOnce() -> SomeType { || { dbg!(&c); c } } You can force a by-move capture by reassigning the capture to a shadowing local at the start of the closure body. The following snippet compiles regardless of whether `SomeType: Copy`: use crab_lib::SomeType; fn callable(c: SomeType) -> impl FnOnce() -> SomeType { || { let c = c; dbg!(&c); c } } With this technique, you never _need_ to resort to `move` in order to write a closure. ## Comprehensive clarification We make the following changes to the closure capture rules as specified in the Reference. At type.closure.capture, we introduce a new capture mode, `ByCopy`: > ## Capture modes > > A _capture mode_ determines how a place expression from the environment is borrowed or moved into the closure. The capture modes are: > > 1. **[NEW] Copy (`ByCopy`) --- The place expression is captured by copying the value into the closure.** > 2. Immutable borrow (`ImmBorrow`) --- The place expression is captured as a shared reference. > 3. Unique immutable borrow (`UniqueImmBorrow`) --- This is similar to an immutable borrow, but must be unique as described below. > 4. Mutable borrow (`MutBorrow`) --- The place expression is captured as a mutable reference. > 5. Move (`ByValue`) --- The place expression is captured by moving the value into the closure. > > > Place expressions from the environment are captured from the first mode that is compatible with how the captured value is used inside the closure body. The mode is not affected by the code surrounding the closure, such as the lifetimes of involved variables or fields, or of the closure itself. > > ### `Copy` values > > Values that implement Copy that are moved into the closure are captured with the **[EDITED]~~`ImmBorrow`~~`ByCopy`** mode. > > > let x = [0; 1024]; > let c = || { > let y = x; // x captured by ByCopy (would have been ImmBorrow before) > }; > And at type.closure.capture.shared-prefix, we account for the new mode: > ### Shared prefix > > In the case where a capture path and one of the ancestors of that path are both captured by a closure, the ancestor path is captured with the highest capture mode among the two captures, `CaptureMode = max(AncestorCaptureMode, DescendantCaptureMode)`, using the strict weak ordering: > > `**[EDITED] ByCopy <** ImmBorrow < UniqueImmBorrow < MutBorrow < ByValue` > > Note that this might need to be applied recursively. > > > // In this example, there are three different capture paths with a shared ancestor: > let s = String::from("S"); > let t = (s, String::from("T")); > let mut u = (t, String::from("U")); > > let c = || { > println!("{:?}", u); // u captured by ImmBorrow > u.1.truncate(0); // u.1 captured by MutBorrow > move_value(u.0.0); // u.0.0 captured by ByValue > }; > c(); > > > Overall this closure will capture `u` by `ByValue`. > > > // **[NEW] example** > let s = 'S'; > let t = (s, 'T'); > let mut u = (t, 'U'); > let c = || { > println!("{:?}", u); // u captured by ImmBorrow > u.1 = '\0'; // u.1 captured by MutBorrow > move_value(u.0.0); // u.0.0 captured by ByCopy > }; > c(); > > > **Overall this closure will capture`u` by `MutBorrow`.** ## Concerns, catches This proposal has a few drawbacks: * In certain niche cases, it could make code less efficient by increasing the amount of copies. However, this is likely dwarfed by the cases made more efficient by getting rid of unneccessary references. * In some extremely niche situations, it could theoretically turn extremely-dubious-but-probably-not-UB `unsafe` code into having UB. Consider the following example: use core::num::NonZeroU8; fn main() { let mut nonzero = NonZeroU8::new(1).unwrap(); unsafe { (&raw mut nonzero).cast::<u8>().write(0); } let _ = || nonzero; // is this Undefined Behavior? } This constructs an invalid `NonZeroU8`, then captures it into a closure, which is subsequently never used. In current Rust, the capture is by-reference, so we never assume `nonzero`'s validity, so (per the rules T-lang is currently FCPing at nail down the final validity rules: references and unions by RalfJung · Pull Request #2337 · rust-lang/reference · GitHub) no UB occurs. However, with this RFC, the capture would become by-value, so we assume validity as soon as the closure is constructed, triggering UB. I believe such code should be rare enough that we don't need to worry about it. ## Case, choices Compared to other proposals to reform closure capturing, this one is a lot smaller, with no new syntax and no breaking changes (except for the one extreme edge case detailed in the previous section). We simply allow more code to Just Work. The only impact on most existing code should be better performance. However, there are a few situations where memory efficiency will suffer: let really_large_copy_value = [42u128; 10_000]; let closure = || if very_unlikely() { drop(really_large_copy_value); } closure(); In today's Rust, the above code will only perform a large stack-to-stack copy if `very_unlikely()` returns `true`. But with this RFC, it will do so unconditionally. We could consider more aggressive designs, over an edition migration. For example, we could say that, in the next edition, the special case for `Copy` is entirely removed. However, this would add a massive footgun to the language: fn main() { let mut copy = false; (|| { copy; copy = true; })(); // Prints `true`, on current Rust and with this RFC. // But if we removed special treatment of `Copy` captures entirely, // it would print `false`. println!("{copy:?}"); } We could also consider increasing the precedence of `ByCopy` to be between `ImmBorrow` and `UniqueImmborrow`, resulting in a capture mode precedende order of `ImmBorrow < ByCopy < UniqueImmBorrow < MutBorrow < ByValue`. This would be a much smaller breaking change, only affecting closures which examine the address of their captures, but still too breaking to do without an edition. I think such behavior would also be quite surprising for people who do run into problems with it. ## Chronicle None known. ## Continuing conundrums * Is the questionable `unsafe` code that would be broken by this proposal really as theoretical as I believe it to be, or is anyone actually doing this cursed thing? * How rare are cases where this change would introduce new undesirable copies? ## Coming chance circumstances * In future editions, we could choose to go all-in on the `let` shadow trick, and deprecate having by-move captures implicitly take precedence over by-reference captures for non-`Copy` types. This would mitigate the fact that implementing `Copy` is technically a breaking change due to its special treatment for closure capture inference. But it would not completely eliminate the semver hazard, so it's unclear that it would be worth the churn. * We could introduce an explicit capturing syntax, e.g. https://github.com/rust-lang/rfcs/pull/3968. First discussed on Zulip.

The SCP Foundation's 'top-secret' archives, declassified for your enjoyment.