Should a `[..]` slice pattern constitute a discriminant read

[meithecatte]

As an unresolved question in the discussion around #138961, it's unclear whether matching [..] against a slice should constitute a read of the length (which would behave like a discriminant read), or if it should behave like a wildcard pattern _.

This affects borrow checking and closure captures.

The behavior implemented for closure captures in #138961 is that [..] does not read the length. @Nadrieril suggests that it would be more consistent to perform the read regardless.

The purpose of this issue is to track the resolution of this spec question and subsequent implementation.

An example program affected by this would be:

fn main() {
    let mut a: &mut [i32] = &mut [1, 2, 3];
    let mut f = || {
        // currently, this does not capture anything.
        // a read of the length would cause a capture of `a`
        let [..] = a;
    };
    a[0] += 1; // mutate `a`. this would not compile if a discriminant read were performed
    f();
}

[Nadrieril]

Thanks for opening this issue!

The difference will affect virtually no one, so this is a question of making the language more predictable. To my knowledge, the patterns that "don't do anything" aka "act like a wildcard" (which includes being invisible for the purposes of borrow-checking and closure capture) are:

• the famous _;
• MyStruct { .. }, MyStruct { field1: _, .. }, MyStruct { field1: [..], .. }, etc;
• [_, _, _], [_, _, ..], [..], etc on arrays, which works just like for structs so that seems fine;
• [..] on slices as is being discussed (but not [_, ..] etc because these branch on the length ofc);
• until recently, full ranges int::MIN..=int::MAX.

I'm proposing the following idea:

• Some types (tuples, structs, arrays, enums with a single variant) are "irrefutable", which means that a pattern for that type only reads something if its fields read something (MyStruct { field1: _, .. } reads nothing, MyStruct { field1: 42, .. } reads the given field etc).
• The rest are "refutable", which means that any non-_ pattern reads at least the discriminant/length/value.

By that rationale, int::MIN..=int::MAX and [..], despite being patterns that can't fail, should constitute a read of the value/length anyway.

[scottmcm]

Hmm, one I could think of [..] is as [_ @ ..], at which point maybe it being not a read like _ is fine, whereas foo @ .. "is" a read to get the length for the binding. The parallel of [..] being like Foo { .. } also sounds right -- not looking at anything about it means there's no read.

But TBH I think I'd be fine with either, if someone can come up with a strong reason that one will be much easier for some reason or another.

[Nadrieril]

We talked about this in today's lang meeting. Consensus was: this is a minor philosophical point which is unlikely to affect anyone, no strong arguments on either side, but overall there is agreement with this change.

Next step would be making a PR that does this change, crater it, and nominate it for t-lang. The Reference should also be updated to clarify this.