No.
First of all, as already noted in comments, you can't toss raw pointers around willy-nilly like that. To quote the documentation of Arc::from_raw
:
The raw pointer must have been previously returned by a call to a Arc::into_raw
.
You absolutely must read the documentation any time you're using an unsafe
method.
Secondly, the conversion you want is impossible. Vec<T>
→ Box<[T]>
works because, internally, Vec<T>
is effectively a (Box<[T]>, usize)
pair. So, all the method does is give you access to that internal Box<[T]>
pointer [1]. Arc<[T]>
, however, is not physically compatible with a Box<[T]>
, because it has to contain the reference counts. The thing being pointed to by Arc<T>
has a different size and layout to the thing being pointed to by Box<T>
.
The only way you could get from Vec<T>
to Arc<[T]>
would be to reallocate the contents of the vector in a reference-counted allocation... which I'm not aware of any way to do. I don't believe there's any particular reason it couldn't be implemented, it just hasn't [2].
All that said, I believe not being able to use dynamically sized types with Arc::into_raw
/Arc::from_raw
is a bug. It's certainly possible to get Arc
s with dynamically sized types... though only by casting from pointers to fixed-sized types.
[1]: Not quite. Vec<T>
doesn't actually have a Box<[T]>
inside it, but it has something compatible. It also has to shrink the slice to not contain uninitialised elements.
[2]: Rust does not, on the whole, have good support for allocating dynamically sized things in general. It's possible that part of the reason for this hole in particular is that Box<T>
also can't allocate arrays directly, which is possibly because Vec<T>
exists, because Vec<T>
used to be part of the language itself, and why would you add array allocation to Box
when Vec
already exists? "Why not have ArcVec<T>
, then?" Because you'd never be able to construct one due to shared ownership.