RFC idea: Result<T, !> implementing Deref<T>

Whether or not it can conceptually be considered one -- I think reasonable people can disagree there -- the fact is that the current Result type hasn't been treated like something that will have Deref, so adding it now is probably not going to happen.

The way you can tell? All of the methods that it has.

Compare, for example, ManuallyDrop::into_inner with MaybeUninit::assume_init. Conceptually these are similar operations: unwrap the value it holds. But ManuallyDrop is Deref, so it's not a method, it's an associated function. Whereas MaybeUninit is not Deref, so it's a method.

Result has too many methods that would be surprises should it be Deref. For example, calling .transpose() on a Result<Matrix, !> would fail, because it would hit the Result version.

Note that there are many people who appreciate that Rust does not even implicitly widen integers (u16 -> u64, and such). Given that, I suspect it'd be a non-starter to even consider expanding coercions to arbitraryily-complicated and frequently-allocating things -- like String: From<&str> being a good example. Doing that kind of thing implicitly would also imply that Cloneing should be implicit too, another thing where many people are happy that Rust makes it visible in the code.

EDIT: Something like AsRef might be plausible, though. Those are, like Deref, restricted enough that most of the complaints about Into don't hold.

3 Likes