Can `new_copy` be explained better? about smallbox

[andylokandy]

Ideally, unsafe blocks should be minimized. In particular new_copy runs afoul of rust-lang/rfcs#2585 It's the write and transmute that requires unsafe?

Yeh, it's a good point. I'll make the update once the RFC is merged.

I suppose your lines like ptr_ptr.write(ptr_addr as usize); could document that they overwrite the pointer but retain any extra data inside the fat pointer.

Sure!

Ain't so idiomatic to pass around multiple references though ...

I think these should not be permanent once const generic is stable.

Why use std::alloc::{alloc.Layout} directly when seemingly Box methods suffice?

Said the std document, the underlying memory layout of Box is not defined and should not be relied on. However, we would have to handle allocation with unsized type on the fly in resize(), where we move data from ?Sized to ?Sized.

[burdges]

new_copy uses Layout::for_value::<U>(val), while Drop uses Layout::for_value::<T>(&*self) (Deref). I suppose new_unchecked should explain that these must always agree. Also into_inner use Layout::new::<T>() but under T: Sized.

[andylokandy]

The real assumption is that T and U has the same type while either can be in sized or unsized form. In this case, the result from Layout::for_value should be the same.

[andylokandy]

Actually, this crate still lacks one important feature, which can't be implemented before(i dont remember why) but now may be viable, that being able to store FnOnce as the unsized type T, and take the ownership on call. Are you interested in investigating it?