Skip to content

Should a [..] slice pattern constitute a discriminant read #141825

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
meithecatte opened this issue May 31, 2025 · 1 comment
Open

Should a [..] slice pattern constitute a discriminant read #141825

meithecatte opened this issue May 31, 2025 · 1 comment
Labels
A-patterns Relating to patterns and pattern matching A-slice-patterns Area: Slice patterns, https://github.com/rust-lang/rust/issues/23121 C-discussion Category: Discussion or questions that doesn't represent real issues. I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-2 Lang team prioritization drag level 2.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang. T-lang Relevant to the language team

Comments

@meithecatte
Copy link
Contributor

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();
}
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 31, 2025
@traviscross traviscross added T-lang Relevant to the language team C-discussion Category: Discussion or questions that doesn't represent real issues. I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-2 Lang team prioritization drag level 2.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang. A-slice-patterns Area: Slice patterns, https://github.com/rust-lang/rust/issues/23121 A-patterns Relating to patterns and pattern matching and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels May 31, 2025
@Nadrieril
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-patterns Relating to patterns and pattern matching A-slice-patterns Area: Slice patterns, https://github.com/rust-lang/rust/issues/23121 C-discussion Category: Discussion or questions that doesn't represent real issues. I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-2 Lang team prioritization drag level 2.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang. T-lang Relevant to the language team
Projects
None yet
Development

No branches or pull requests

4 participants