RFC: Remove cross-borrowing

[pcwalton]

• Start Date: 2014-06-09
• RFC PR #: (leave this empty)
• Rust Issue #: #10504

Summary

Remove the coercion from Box<T> to &T/&mut T from the language.

Motivation

Currently, the coercion between Box<T> to &mut T can be a hazard because it can lead to surprising mutation where it was not expected. Furthermore, it is inconsistent with user-defined smart pointers because user-defined smart pointers cannot implicitly coerceto &T or &mut T.

Detailed design

The coercion between Box<T> and &T/&mut T should be removed.

Note that methods that take &self/&mut self can still be called on values of type Box<T> without any special referencing or dereferencing. That is because the semantics of auto-deref and auto-ref conspire to make it work: the types unify after one autoderef followed by one autoref.

Drawbacks

Borrowing from Box<T> to &T/&mut T may be convenient.

Alternatives

An alternative is to apply the method autoderef/autoref rules to all coercions in the language. This makes the mutability hazard more prevalent, however.

The impact of not doing this is that the coercion will remain.

Unresolved questions

None.

[nrc]

Another alternative would be to disallow coercion to &mut T but keep the coercion to &T (removing the surprising mutability thing but keeping the convenience). We could (should?) also allow that coercion for other smart pointers. We might want to think of a more general solution around coercions though.

[emberian]

+1. Let's get rid of this special case.

[lilyball]

+1 to removing coercion to &mut T. I'm in favor of adding coercion from smart pointers to &T (via autoref+autoderef) in more places, notably in function parameters. The main argument in favor of this is so String and Vec<T> can auto-borrow to &str and &[T] without having to call .as_slice(), which fixes what I believe to be the largest usability issue with String/Vec today (this assumes that both types will implement Deref once DST lands, but there seems to be near-universal support for that idea every time I've seen it brought up).

[sfackler]

I've always thought that implicit coercion to &T was a bit sad since it makes it harder to tell if something's moving or not, but it is super painful to tack on as_slice() all over the place.

[lilyball]

@sfackler Without this, post-DST with Deref we can at least start saying &*string_var, but it's still awkward (just not as painful as .as_slice()).

[huonw]

+1

Cross borrowing to &T can be added in a generic way later, via a separate RFC (if we decide we do want it).

[bstrie]

I'm all for removing special cases, but I do hope that eventually we reimplement it in a general way for user-defined smart pointers. Writing APIs that take references is our best means of avoiding combinatorial function explosion, but I've never seen anything but grumpiness and incredulity about the &* construction.

[alexcrichton]

This was discussed two weeks ago and we decided to merge.