Open
Description
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();
}
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
Nadrieril commentedon Jun 1, 2025
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:
_
;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);int::MIN..=int::MAX
.I'm proposing the following idea:
MyStruct { field1: _, .. }
reads nothing,MyStruct { field1: 42, .. }
reads the given field etc)._
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 commentedon Jun 18, 2025
Hmm, one I could think of
[..]
is as[_ @ ..]
, at which point maybe it being not a read like_
is fine, whereasfoo @ ..
"is" a read to get the length for the binding. The parallel of[..]
being likeFoo { .. }
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 commentedon Jul 2, 2025
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.