Review potential implementors for `TransparentWrapper`
Opened this issue · 2 comments
HeroicKatora commented
The library itself provides no implementors for the trait trait. This is odd as there are several transparent wrappers within the standard library. Some of them might be valid, some less so.
core::mem::ManuallyDrop<T>
core::num::Wrapping
Invalid ones:
core::cell::Cell
: This would allow turning a&T
into a&Cell<T>
and subsequently write to memory that was assumed to be read-only. ButCell::from_mut
exists and so a purely mutable variant would be valid. Unclear about the wrapping of niches.core::mem::MaybeUninit
: Would allow writing uninitialized memory to the referree. Here only a non-mutable variant would be valid. Unclear about the wrapping of niches.core::pin::Pin
: This basically constructs aPin
and would thus violate some of its safety assumptions of theunsafe
constructor. However, it might be possible to gate such animpl
with the same bounds asPin::new
. There is no way for a purely mutable or immutable variant that does not adhere to the same rules as even cloning thePin
is a safety critical operation.core::task::Waker
: Another example of a type that isunsafe
to construct.
Unclear:
core::cell::UnsafeCell
: Highly dubious for the reasons ofCell
. But itself it does not expose any safe method for writing so it is arguably a pure wrapper on its own that only affects the languages treatment of references and pointers (in stacked borrowed) themselves. Unclear about the wrapping of niches.std::io::IoSlice{,Mut}
: This is actually a transparent wrapper around a target dependent underlying type such aslibc::iovec
onunix
.
HeroicKatora commented
This poses another question: Is the trait's description actually precise enough to explain the valid and invalid uses above?
HeroicKatora commented
One more unclear implementation (this SemVer is compatible, right?):
impl<T, U> TransparentWrapper<[U]> for [T]
where T: TransparentWrapper<U>
{ }
An alternative would be to introduce this as a pair of methods instead.