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 entirely #139

Merged

Conversation

pcwalton
Copy link
Contributor

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

Summary

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

Motivation

The coercion between Box<T> to &T is not replicable by user-defined smart pointers and has been found to be rarely used 1. We already removed the coercion between Box<T> and &mut T in RFC 33.

Detailed design

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

Note that methods that take &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 may be convenient.

Alternatives

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

Unresolved questions

None.

@lilyball
Copy link
Contributor

This RFC does not consider the desire to be able to cross-borrow from String to &str and from Vec<T> to &[T]. There has been talk of implementing Deref<str> on String once DST lands (and Deref<[T]> on Vec<T>), which would allow a String to be turned into a &str with &*s.

Given that, it was also suggested that cross-borrowing from Box<T> to &T should be expanded to cover Deref in general, allowing String to cross-borrow to &str. Doing this requires that cross-borrowing from Box<T> to &T be left in place.

I don't know if we really need cross-borrowing form String to &str, or if &*s is sufficient, but it would be used a lot if we had it. Note that we used to support cross-borrowing from ~str to &str (and ~[T] to &[T]) and the need to add .as_slice() everywhere has generally been considered the most annoying part of the transition to String/Vec<T>.

@huonw
Copy link
Member

huonw commented Jun 26, 2014

👍 to the RFC.

Doing this requires that cross-borrowing from Box to &T be left in place.

No, it doesn't. Box will be able to get cross-borrowing via the same general mechanism.

@lilyball
Copy link
Contributor

@huonw This RFC is about removing cross-borrowing entirely, not about changing the particular implementation detail that allows Box<T> to cross-borrow to &T.

@pcwalton
Copy link
Contributor Author

As I said in the original PR, I would like to have a consistent system for now. We can introduce a more flexible cross-borrow system later.

@lilyball
Copy link
Contributor

@pcwalton Ok, so you don't view this RFC as being a reason to reject the reintroduction of cross-borrowing later via Deref? In that case, I have no objection.

@huonw
Copy link
Member

huonw commented Jun 26, 2014

We remove our current implementation of cross-borrowing, which only affects Box (having Box super-special like this is weird and inconsistent), and then later we can possibly add a generalised form using Deref that all pointer-like types can use, including Box.

Removing the special case now doesn't preclude adding the general case later.

@nrc
Copy link
Member

nrc commented Jun 26, 2014

I fought quite strongly against this before. I have been totally convinced by @huonw 's stats though, so +1.

@bstrie
Copy link
Contributor

bstrie commented Jun 26, 2014

@kballard, don't worry, you're not the only one who likes cross-borrowing in theory.

This RFC should be a no-brainer: we're just removing a special case with the sentiment that it should be brought back later in a more general form. +1

@pcwalton
Copy link
Contributor Author

pcwalton commented Jul 1, 2014

This was accepted.

@alexcrichton alexcrichton merged commit aaaa563 into rust-lang:master Jul 3, 2014
@alexcrichton
Copy link
Member

This was discussed a few days ago and no objects have been raised since then. This has now been merged.

@aturon
Copy link
Member

aturon commented Jul 4, 2014

For the record: some objections were raised by @wycats on IRC, namely that this would make it impossible to go from Box<Trait> to &Trait in safe code. Further details are available on the tracking issue.

withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017
@Centril Centril added A-references Proposals related to references A-allocation Proposals relating to allocation. A-typesystem Type system related proposals & ideas A-coercions Proposals relating to coercions. and removed A-allocation Proposals relating to allocation. labels Nov 23, 2018
wycats pushed a commit to wycats/rust-rfcs that referenced this pull request Mar 5, 2019
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.

8 participants