Conventions for the use of `Deref` and `DerefMut`

[rust-highfive]

This was discussed previously in rust-lang/rust#13126.

Tracking issue for postponed PR #25

[nrc]

I am keen to see some guidance here. In particular, I find deref'ing to an unrelated type for the sake of convenience a confusing anti-pattern. My preference would be for deref to only be used for getting the contents of a smart pointer and for taking a slice of a collection, but I'm sure there are other similar cases I haven't thought of. However, using deref for polymorphism using method calls seems pretty bad.

cc @aturon

[huonw]

What is 'unrelated'?

[nrc]

E.g., https://github.com/rust-lang/rust/blob/1614d92f5179d3fd947fedc903bd13b0824a42de/src/librustc_resolve/check_unused.rs#L36

[aturon]

@nick29581 Yes, I am also anxious to establish some guidelines here; it's coming up increasingly often in std API designs.

[nrc]

Also InternedString in syntax::parse::token this is a wrapper around a wrapper around an Rc<str> and so it sort of makes sense for it to be Deref. However, to me that seems like an implementation detail, because it is advertised as a kind of string, rather than a smart pointer. So, it seems that Deref is wrong in this case. But perhaps it should be deref for the same reason String is. In any case it seems borderline and thus an interesting case to consider.

[brson]

Derefing an InternedString in rustc can panic if the TLS invariants are violated, unlike with String.

[nrc]

My view: https://github.com/nrc/patterns/blob/master/anti_patterns/deref.md

[whitequark]

E.g., https://github.com/rust-lang/rust/blob/1614d92f5179d3fd947fedc903bd13b0824a42de/src/librustc_resolve/check_unused.rs#L36

I wondered if that Deref impl got removed, but no, it's still there: https://github.com/rust-lang/rust/blob/02f5786a324c40b2d8b2d0df98456e48fb45d30c/src/librustc_resolve/check_unused.rs