Skip to content

RFC: Remove cross borrowing entirely #139

New issue

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

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

Already on GitHub? # to your account

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
# for free to join this conversation on GitHub. Already have an account? # 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