deref_patterns
: let string and byte string literal patterns peel references and smart pointers before matching
#140658
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This follows up on #140028. Together, they allow using string and byte string literal patterns to match on smart pointers when
deref_patterns
is enabled. In particular, string literals can now match onString
, subsuming the functionality of thestring_deref_patterns
feature.More generally, this works by letting literals peel references (and smart pointers) before matching, similar to most other patterns, providing an answer to #44849. Though it's only partially implemented at this point: this doesn't yet let named const patterns peel before matching. The peeling logic is general enough to support named consts, but the typing rules for named const patterns would need adjustments to feel consistent (e.g. arrays would need rules to be usable as slices, and
const STR: &'static str
wouldn't be able to match on aString
unless a rule was added to let it be used where astr
is expected, similar to what #140028 did for literals).This also allows string and byte string patterns to match on mutable references, following up on #140028 (comment). Rather than forward the mutability of the scrutinee to literal patterns, I've opted to peel
&mut
s from the scrutinee. From a design point of view, this makes the behavior consistent with what would be expected from deref coercions using the methodology in the next paragraph. From a diagnostics point of view, this avoids labeling string and byte string patterns as "mutable references", which I think could be confusing. Seebyte-string-type-errors.rs
for how the diagnostics look.At a high level, the peeling logic implemented here tries to mimic how deref coercions work for expressions: we peel references (and smart pointers) from the scrutinee until the pattern can match against it, and no more. This is primarily tested by
const-pats-do-not-mislead-inference.rs
. To illustrate the connection, I wasn't sure if this made sense to include in the test file, but I've translated those tests to make sure they give the same inference results as deref coercions: (playground). In each case, a reference to the scrutinee is coerced to have the type of the pattern (under a reference).Tracking issue for deref patterns: #87121
r? @oli-obk
cc @Nadrieril