I don’t think that there should be a problem with adding this impl.
For now, can you make use wrapper type?
struct ShareVec<T>(Rc<Vec<T>>);
impl<T> AsRef<[T]> for ShareVec<T> {
fn as _ref(&self) -> &[T] {
self.as_slice()
}
}
fn main() {
let v = Rc::new(vec!());
let c = Cursor::new(v.clone());
}
That’s a pity. CAD97. But logically AsRef<[u8]> should be implemented. I’m more interested in correcting std than my own code (as my own code is now “optimal”).
Unfortunately, the whole point of the Rc was to be reference counted to avoid having to copy the vector.
Is there a reason to have an Rc<Vec<u8>> in the first place, considering Rc disallows mutable access? It seems more reasonable to me to convert your vector to Rc<[T]> via From right from the start.
let v: Rc<[YourType]> = vec!().into();
let c = Cursor::new(v.clone());
As far as I can tell it’s also impossible to make an Rc<[T]> without having two copies of the slice data exist simultaneously at some point, making it useless for the seemingly ideal use case of data that is dozens of gigabytes large. Rc<Vec<T>> doesn’t have this problem.
(Basically, no matter how you try to create an Rc<[T]>, at some point you require a [T] so that the length is known, and then there must be a (&[T]) -> Rc<[T]> allocation and memcpy to embed the refcounts)
Oh, I see, the issue is that the Rc has to allocate space for the control block containing the strong & weak refcounts. That is a really subtle performance pitfall imo. But in any case, thank you for explaining this to me and sorry for the noise.