Skip to content

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

Open
@meithecatte

Description

@meithecatte
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();
}

Activity

added
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on May 31, 2025
added
T-langRelevant to the language team
C-discussionCategory: Discussion or questions that doesn't represent real issues.
I-lang-nominatedNominated for discussion during a lang team meeting.
P-lang-drag-2Lang team prioritization drag level 2.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang.
A-slice-patternsArea: Slice patterns, https://github.com/rust-lang/rust/issues/23121
A-patternsRelating to patterns and pattern matching
and removed
needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.
on May 31, 2025
Nadrieril

Nadrieril commented on Jun 1, 2025

@Nadrieril
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.

scottmcm

scottmcm commented on Jun 18, 2025

@scottmcm
Member

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

Nadrieril commented on Jul 2, 2025

@Nadrieril
Member

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.

added
I-lang-radarItems that are on lang's radar and will need eventual work or consideration.
and removed
I-lang-nominatedNominated for discussion during a lang team meeting.
P-lang-drag-2Lang team prioritization drag level 2.https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang.
on Jul 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-patternsRelating to patterns and pattern matchingA-slice-patternsArea: Slice patterns, https://github.com/rust-lang/rust/issues/23121C-discussionCategory: Discussion or questions that doesn't represent real issues.I-lang-radarItems that are on lang's radar and will need eventual work or consideration.T-langRelevant to the language team

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @traviscross@Nadrieril@scottmcm@meithecatte@rustbot

        Issue actions

          Should a `[..]` slice pattern constitute a discriminant read · Issue #141825 · rust-lang/rust