.as_deref() on Option<Box<String>> does not resolve to Option<&str> as expected

[VinEckSie]

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:

fn main() {
    let user_mail: Option<Box<String>> = Some(Box::new("mail@example.com".to_string()));

    // This should return Option<&str>
    let string_slice = user_mail.as_deref();

    match string_slice {
        Some("mail@example.com") => println!("Matched!"),
        Some(other) => println!("Other: {}", other),
        None => println!("None"),
    }
}

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("mail@example.com") => println!("Matched!"))

error[E0308]: mismatched types
  expected `&String`
     found `&str`

Meta

• ✅ Bug still occurs on stable (1.86.0)
• ✅ Bug also occurs on beta
• ✅ Bug also occurs on nightly

rustc --version --verbose:

rustc 1.86.0 (05f9846f8 2025-03-31)
binary: rustc
commit-hash: 05f9846f893b09a1be1fc8560e33fc3c815cfecb
commit-date: 2025-03-31
host: x86_64-apple-darwin
release: 1.86.0
LLVM version: 19.1.7

Backtrace

Not applicable — no panic occurred.

---

💡 Workaround (Manual Pattern Matching)

While .as_deref() fails to resolve as expected, the following pattern using .as_str() works correctly and behaves as intended:

fn main() {
    let user_mail: Option<Box<String>> = Some(Box::new("mail@example.com".to_string()));

    match user_mail {
        Some(ref boxed_string) if boxed_string.as_str() == "mail@example.com" => {
            println!("user mail OK!");
        }
        Some(ref other) => {
            println!("user mail KO!: {}", other);
        }
        None => {
            println!("No user email");
        }
    }
}

[zachs18]

Option::as_deref does not perform deref coercions, it derefs exactly once.

More specifically, it takes an &Option<T> where T: Deref¹ 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

match user_email.as_ref().map(|ref_to_boxed_string| ref_to_boxed_string.as_str()) {
    Some("mail@example.com") => println!("Matched!"),
    Some(other) => println!("Other: {}", other),
    None => println!("None"),
}
// or
match user_email.as_deref().map(|ref_to_string| ref_to_string.as_str()) {
  // ...
}

(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

1. The reason you can call it on an Option<T> is due to auto-referencing when using the dot operator for method calls). ↩

[VinEckSie]

Thanks a lot for the clear explanation!

I’ll use that workaround and follow #87121 for future improvements.