Built a crate to safely share `Box` and `Vec` manually

If you are looking for ideas on how to expand or improve the crate, here are a few suggestions that would make it even more ergonomic:

1. Implement Deref and DerefMut Right now, users have to explicitly call .get() on SharedBoxRef and .as_slice() / .as_slice_mut() on the Vec types. If you implement the standard std::ops::Deref (and DerefMut for SharedVecPart), users could transparently use these types exactly like standard references or slices (e.g. calling slice methods directly on SharedVecPart without the .as_slice() boilerplate).

2. Allow SharedVecPart to be split further Currently, SharedVecMut can spawn parts, but what if a worker thread receives a SharedVecPart and wants to split the work again across its own sub-threads? If you added split_off and split_to methods directly to SharedVecPart (and maybe a try_merge method so sibling parts can be glued back together if they are contiguous), it would enable recursive work-stealing patterns!

3. Implement IntoIterator Adding IntoIterator for &SharedVecRef, &mut SharedVecPart, etc., would make iterating over the shared vectors much cleaner in for loops, rather than forcing the user to extract the slice and call .iter_mut() manually.

Thanks for responding. I'll definitely take in the last advice. For Arc<Vec<T>>, you can also check out arc-slice.

I'll definitely implement these convenient traits.
The second suggestion of allowing reference types to further create their own references may fundamentally change the crate. I'll further consider about it.

all you have to do is add T : ?Sized on the generics for your SharedBox (except on SharedBox::new), and use size_of_val instead of size_of if you want to check the size

I mean something like:

let b = SharedBox::new(non_send_value);
let b_ref = b.borrow();
std::thread::spawn(move || use_non_send_value(b.get()));
use_non_send_value(b_ref.get());

This only requires SharedBox to be Send and not SharedBoxRef.

Thanks, I'll do that.

Thanks. I haven't thought about this case.
Also need to fix for SharedVec.
I don't think SharedVecMut needs it.