-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
RFC: Remove cross borrowing entirely #139
Conversation
This RFC does not consider the desire to be able to cross-borrow from Given that, it was also suggested that cross-borrowing from I don't know if we really need cross-borrowing form |
👍 to the RFC.
No, it doesn't. |
@huonw This RFC is about removing cross-borrowing entirely, not about changing the particular implementation detail that allows |
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. |
@pcwalton Ok, so you don't view this RFC as being a reason to reject the reintroduction of cross-borrowing later via |
We remove our current implementation of cross-borrowing, which only affects Removing the special case now doesn't preclude adding the general case later. |
I fought quite strongly against this before. I have been totally convinced by @huonw 's stats though, so +1. |
@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 |
This was accepted. |
This was discussed a few days ago and no objects have been raised since then. This has now been merged. |
For the record: some objections were raised by @wycats on IRC, namely that this would make it impossible to go from |
fixed small typo for tasks
Ember.String.isHtmlSafe RFC
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 betweenBox<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 typeBox<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.