You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calling .as_deref() on an Option<Box> does not resolve to Option<&str> as expected.
It seems to resolve to Option<&Box>, leading to a type mismatch (expected &str, found &String) when pattern matching string literals.
This behavior is unexpected, especially given that Box should deref to String, and String to str.
I expected to see this happen: .as_deref() on Option<Box> should dereference all the way to Option<&str>, making it matchable with &str literals directly.
Instead, this happened: (mail underlined on this line : Some("[email protected]") => println!("Matched!"))
error[E0308]: mismatched types
expected `&String`
found `&str`
Option::as_deref does not perform deref coercions, it derefs exactly once.
More specifically, it takes an &Option<T> where T: Deref1 and returns an Option<&<T as Deref>::Target>. Here, you have T = Box<String>, and <Box<String> as Deref>::Target = String, so you get a Option<&String> (Not an Option<&Box<String>>, that's what Option::as_ref would give here).
If you don't want to need to do manual pattern matching, you can also do something like
(There is work happening towards having matching on smart pointers Just Work:tm: with the deref target as the type in the pattern, but it is not finished yet: #87121 )
(I wonder if there is T-libs-api appetite for something like Option::bikeshed_map_deref, since in my experience it is fairly common to have an Option<&T> and want an Option<&<T as Deref>::Target>, which Option::as_deref does not do. That alone wouldn't make the OP example a single call though; you'd still need to do like .as_deref().map_deref() to go from Option<Box<String>> to Option<&str>.)
Footnotes
The reason you can call it on an Option<T> is due to auto-referencing when using the dot operator for method calls). ↩
jieyouxu
added
C-discussion
Category: Discussion or questions that doesn't represent real issues.
and removed
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
C-bug
Category: This is a bug.
labels
Apr 10, 2025
Calling .as_deref() on an Option<Box> does not resolve to Option<&str> as expected.
It seems to resolve to Option<&Box>, leading to a type mismatch (expected &str, found &String) when pattern matching string literals.
This behavior is unexpected, especially given that Box should deref to String, and String to str.
I tried this code:
I expected to see this happen: .as_deref() on Option<Box> should dereference all the way to Option<&str>, making it matchable with &str literals directly.
Instead, this happened: (mail underlined on this line : Some("[email protected]") => println!("Matched!"))
Meta
stable
(1.86.0)beta
nightly
rustc --version --verbose
:Backtrace
💡 Workaround (Manual Pattern Matching)
While
.as_deref()
fails to resolve as expected, the following pattern using.as_str()
works correctly and behaves as intended:The text was updated successfully, but these errors were encountered: