Add more Zeroable and ZeroableInOption impls

[a1phyr]

No description provided.

[Lokathor]

For the wide pointer/reference types, I'm unclear on the metadata requirements.

Does a null pointer not need a valid length?

and does the None not even need a vtable?

and where specifically is there documentation about this? I'd rather not add the impls if there's no docs about it.

[zachs18]

The layout of pointers to unsized types is currently explicitly unspecified in the reference, aside from being Sized and having size and alignment at least that of pointers to sized types. So conservatively (and perhaps pedantically), I'd say the metadata requirements are "unspecified" in stable Rust, and these impls make more assumptions than stable Rust guarantees.

That being said: I do think some reasonable assumptions can be made, especially under the ptr_metadata unstable feature.

For the wide pointer/reference types, I'm unclear on the metadata requirements.
Does a null pointer not need a valid length?

I think it is reasonable to assume that a Zeroable::zeroed() slice raw pointer would be a null pointer with a length of 0 (which is valid; you could get it from safe unsizing, e.g. std::ptr::null::<[T; 0]>() as *const [T]).

and does the None not even need a vtable?

It's not mentioned in the documentation that I can find, but for specifically Option<Box<T>/etc> where T is dyn Trait, I would assume that it cannot require the metadata be a valid vtable, since it may be that no valid vtable even exists, (e.g. None::<&dyn Trait> where Trait has no implementations).

(Not evidence, but under the current implementation: None::<&T> just leaves the "metadata" part of the "pointer" uninitialized, so zeroed is fine.)

---

I would hesistate to add impls of ZeroableInOption for String and Vec mostly just because they don't feel very "primitive" to me, but also due to lack of layout guarantees (despite Vec's relatively strict guarantees about being a (null-pointer-optimized pointer, length, capacity) triplet (in unspecified order)).

Other than that, I agree that it'd probably be best not to add these until there is stable documentation to support that they are sound, though perhaps they could be added under a cargo feature until then?.

(I also agree with the comment in the code that impls like impl<T: ?Sized> Zeroable for *const T where <T as Pointee>::Metadata: Zeroable would be nice since they would encompass thin T: Sized and extern type pointers, slice pointers, possible future custom DSTs, and structs with one of those as their unsized tail.)

[a1phyr]

I removed the problematic String and Vec impls. Is it enough or do you want me to remove more of them ?

[Lokathor]

I think we're good like this