Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Remove cross-borrowing #112

Merged
merged 2 commits into from
Jun 25, 2014

Conversation

pcwalton
Copy link
Contributor

@pcwalton pcwalton commented Jun 9, 2014

  • 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
Copy link
Member

nrc commented Jun 9, 2014

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
Copy link
Member

emberian commented Jun 9, 2014

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

@lilyball
Copy link
Contributor

lilyball commented Jun 9, 2014

+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
Copy link
Member

sfackler commented Jun 9, 2014

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
Copy link
Contributor

lilyball commented Jun 9, 2014

@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
Copy link
Member

huonw commented Jun 10, 2014

+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
Copy link
Contributor

bstrie commented Jun 10, 2014

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.

pcwalton added a commit that referenced this pull request Jun 25, 2014
Accepted RFC #32: Remove cross-borrowing
@pcwalton pcwalton merged commit 1a061dd into rust-lang:master Jun 25, 2014
@pcwalton pcwalton deleted the remove-cross-borrowing branch June 25, 2014 00:26
@alexcrichton
Copy link
Member

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

@Centril Centril added A-coercions Proposals relating to coercions. A-typesystem Type system related proposals & ideas A-references Proposals related to references labels Nov 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-coercions Proposals relating to coercions. A-references Proposals related to references A-typesystem Type system related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants