liballoc: implement From for Box, Rc, Arc #29580
Conversation
Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
```
fn i_will_work_with_arc<T: Into<Arc<MyTy>>>(t: T) {
let the_arc = t.into();
// Do something
}
i_will_work_with_arc(MyTy::new());
i_will_work_with_arc(Box::new(MyTy::new()));
let arc_that_i_already_have = Arc::new(MyTy::new());
i_will_work_with_arc(arc_that_i_already_have);
```
Please note that this patch doesn't work with DSTs.
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @brson (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
Thanks for the PR! Unfortunately there's now way to have an impl of a trait be unstable, and as these are for some particularly "core types" it's a weighty addition! As a result I'm going to tag this with I would personally want to eschew the |
alexcrichton
added
the
T-libs-api
|
It was also suprising for me to find out that there is no 'legitimate' way of conversion unsized data from one smart pointer to another (or maybe I just did not find it?), because from the naive point of view this is kind of simplest operation (move the pointer and that's it). Even for sized types, if I understood the code correctly, in |
|
@alexbool There is no free way to move from |
|
Ah yeah, I see that |
C++ supports creation of shared pointers from raw pointers, so |
You can manually allow the two-allocation mode for specific traits by implementing the trait for use std::rc::Rc;
trait A {
fn blub(&self) { println!("blub") }
}
struct X;
impl A for X {
fn blub(&self) { println!("X") }
}
impl<T: A + ?Sized> A for Box<T> {
fn blub(&self) { (**self).blub() }
}
fn main() {
let x = Box::new(X);
let y: Box<A> = x;
let z: Rc<A> = Rc::new(y);
z.blub();
} |
|
The libs team discussed this during triage today and we're fine merging this, although could you remove the |
|
Done |
|
Oops, there are some errors from make-tidy. |
| @@ -894,6 +895,13 @@ impl<T: ?Sized + Hash> Hash for Arc<T> { | |||
| } | |||
| } | |||
|
|
|||
| #[stable(feature = "rust1", since = "1.6.0")] | |||
There was a problem hiding this comment.
Ah these attributes are fine, but they'll need a new feature name as rust1 is already taken. Perhaps something like from_for_ptrs or something like that?
|
Fixed |
|
⌛ Testing commit 67c07d4 with merge 99093b7... |
Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
```rust
fn i_will_work_with_arc<T: Into<Arc<MyTy>>>(t: T) {
let the_arc = t.into();
// Do something
}
i_will_work_with_arc(MyTy::new());
i_will_work_with_arc(Box::new(MyTy::new()));
let arc_that_i_already_have = Arc::new(MyTy::new());
i_will_work_with_arc(arc_that_i_already_have);
```
Please note that this patch doesn't work with DSTs.
Also to mention, I made those impls stable, and I don't know whether they should be actually stable from the beginning. Please tell me if this should be feature-gated.
|
@alexbool I see corresponding tests for Rc and Arc, but not for Box. Is this an oversight? |
Sometimes when writing generic code you want to abstract over
owning/pointer type so that calling code isn't restricted by one
concrete owning/pointer type. This commit makes possible such code:
Please note that this patch doesn't work with DSTs.
Also to mention, I made those impls stable, and I don't know whether they should be actually stable from the beginning. Please tell me if this should be feature-gated.