Miss Dada  🏳️‍⚧️

I would like to nominate `Option::as_deref` for the worst named method in Rust

what would you call it? ... i remember being kind of frustrated by how long it was unstable because of that particular bikeshed, and it’s really way nicer than .map(|x| &*x)

First preference: `Deref` was just structured in a way it could be implemented by `Option<impl Deref>`. Second preference: Inherent method called `deref` Third+ preference: Something that implies it's *calling* deref on its member, e.g. `derefed`.

how would the first preference work? how do you handle None?

It'd return `None`. This would require GATs so that it was `fn deref(&self) -> Self::Target<'_>`, letting you return an option of a reference for example.

oh I'd not thought of it like that: of course Option<T> could impl Deref with Target = Option<<T as Deref>::Target>, which wouldn't make Option<T> transparently equal to T under Deref, but I'd not considered the lifetime problem that requires GAT

Ironically you can almost implement this for `Option`, since null ptr optimization means that `&T == &Option<T>` in terms of layout. Except it's not particularly useful since that'd require `T: Sized`, meaning `Option<String>` couldn't impl `Deref`