Cromulent Copy closure captures - #4011

I've added a note about potential breakage around the auto traits a closure is inferred to implement, and how we could resolve that breakage.

Thank you for creating an RFC that taught me what the word cromulent means. By which I mean you did not provide this information, but upon seeing the RFC, I looked it up.

I've updated the RFC to clarify that capturing values behind a reference still happens by-reference:

let x = &([0; 1024],);
let c = || {
    let y = x.0; // x.0 captured by ImmBorrow
};

I've now implemented this RFC: rust-lang/rust#163717

The RFC text has been updated with lessons from the implementation.

I've added a note about potential breakage around the auto traits a closure is inferred to implement, and how we could resolve that breakage.

I've now gotten rid of this breakage entirely.

I've added a special case for the comparison operators (==, !=, <, <=, >=, >) in order to resolve an issue fond during the Crater run.

^{(only saw this due to looking at the list of most recent RFCs by accident, while looking something else up)}

This reminds me of an idea @nikomatsakis and I have discussed at some point, but which may not be written down anywhere AFAIK:

Here, a and b are both captured by-ref but b doesn't live long enough:

let a = "a".to_string();
let concat_a_b = {
    let b = "b".to_string();
    || format!("{a}{b}")
}; // <- `b` drops here today, causing an error.
println!("{}", concat_a_b());

// Ideally, this would also work
// (i.e. `a` wouldn't need to be moved into the closure).
println!("{a}");

The error is even quite precise about what's going on:

closure may outlive the current block, but it borrows b, which is owned by the current block

Capture modes need to be known strictly before borrowck, and also, in the past, there have been decisions made against borrowck information controlling behavior (which is why let x = &foo(); rules were initially a list of special cases etc.).

But even during typeck, typeof(concat_a_b) (aka typeof({...; || ... }) aka typeof(|| ...)) is known to contain either typeof(b) or typeof(&b) (depending on the eventually-decided capture mode), simply because that closure captures b.

In many cases, slapping the move keyword on all affected closures is enough, but sometimes explicit references are needed, for the other captures (a in the example above) to not also get moved into the closure.

So a potential simple ruleset for a conservatively correct approximation of "guaranteed to fail borrowck because of scoping" (modulo dead code? not sure what the actual limits are), may be:

1. expression E's type contains (i.e. is covariant/invariant wrt) closure C's type
   (if E is the function body, its type would need to be the function return type)
2. closure C captures variable V
3. variable V is syntactically outlived by E
   (e.g. E contains the parent block/match, that declares V)

As the expectation is that borrowck would fail, those rules could be used to determine that capture mode should be move, for every such variable V, without changing the behavior of any code that already compiles successfully.

Whether that kind of change should be made, is a different matter entirely, and there's a chance it's been proposed elsewhere already (and rejected/postponed), I have not looked into whether that had happened.

I'd say you're cheating on the "borrowck shouldn't influence captures" rule by morally doing a bit of lexical borrow-checking on HIR :p Interesting angle nevertheless.