Document how closure capturing interacts with discriminant reads #1837
Conversation
This is the behavior after the bugfixes in rustc PR 138961.
rustbot
added
the
S-waiting-on-review
| r[type.closure.capture.precision.discriminants] | ||
| ### Capturing for discriminant reads | ||
|
|
||
| If pattern matching requires inspecting a discriminant, the relevant place will get captured by `ImmBorrow`. |
There was a problem hiding this comment.
Unless we mutably access the contents, right? E.g.
let c = || match x {
(Example::A(ref mut _y), _) => println!("variant A"),
(Example::B(_), _) => println!("variant B"),
};Is that already implied by the other rules?
There was a problem hiding this comment.
ok yep, that's the "Shared prefix" thing
There was a problem hiding this comment.
Yup. Do you think this deserves a clarification? (if so, how would you word it)
There was a problem hiding this comment.
no, I think it's clear in the context
| c(); | ||
| ``` | ||
|
|
||
| Likewise, a slice pattern that matches slices of all possible lengths does not constitute a discriminant read. |
There was a problem hiding this comment.
We're talking about changing this behavior. cc @Nadrieril.
That said, I think we should merge it in this form, and then update this when we've changed this behavior.
There was a problem hiding this comment.
Yes, the idea to change this came from the PR that is being documented by this change.
traviscross
added
the
S-waiting-on-stabilization
| Likewise, a slice pattern that matches slices of all possible lengths does not constitute a discriminant read. | ||
|
|
||
| ```rust | ||
| let mut x: &mut [i32] = &mut [1, 2, 3]; |
There was a problem hiding this comment.
| let mut x: &mut [i32] = &mut [1, 2, 3]; | |
| let x: &mut [i32] = &mut [1, 2, 3]; |
| the slice pattern needs to inspect the length of the scrutinee. | ||
|
|
||
| ```rust,compile_fail,E0506 | ||
| let mut x: &mut [i32] = &mut [1, 2, 3]; |
There was a problem hiding this comment.
| let mut x: &mut [i32] = &mut [1, 2, 3]; | |
| let x: &mut [i32] = &mut [1, 2, 3]; |
| Matching against a [range pattern][patterns.range] constitutes a discriminant read, even if | ||
| the range matches all possible values. |
There was a problem hiding this comment.
I'm not quite following this terminology, particularly around the user of the term "discriminant". My understanding is that a discriminant is specifically a tag associated with an enum. I wouldn't consider an integer to have a discriminant. Can you clarify what this means?
There was a problem hiding this comment.
Right, this happened because the relevant rustc has a distinction between (a) binding sub-values to identifiers with various binding modes, and (b) discriminant reads—with other "shallow/immediate" reads, such as the length field of a slice, being shoe-horned into the category of discriminant reads.
From the perspective of reference text, this obviously doesn't make sense. I'll rephrase that as just "constitutes a read", I think, unless you have any better ideas on how to word this?
| Matching against a [slice pattern][patterns.slice] constitutes a discriminant read if | ||
| the slice pattern needs to inspect the length of the scrutinee. |
There was a problem hiding this comment.
Same question about the use of the term "discriminant".
This is the behavior after the bugfixes in rust-lang/rust#138961. I have successfully ran
mdbook testwithRUSTUP_TOOLCHAINpointed at a stage1 built on top of the aforementioned PR – until it's merged, the CI here will fail.