Open m-mueller678 opened 8 months ago
Doesn't NoUninit have a derive already?
It does, but it does not permit interior mutability. I'm looking for a more relaxed version of NoUninit
Ah, right.
Well then as you say, I'm not sure what operation such a trait allows, since the interior mutability part makes most things probably not work quite right.
I don't think this alone allows you to implement any useful operations. It just offloads some of the work of manual checking onto the type system. I definitely want a trait like that, but making a new crate just for this one marker trait feels overkill. So I thought, bytemuck would be a good place to put it.
If it doesn't allow at least one operation I'm unclear why you'd want to put the info in the type system though.
I use it as a bound on traits that have additional requirements which must be checked manually
I would like a marker trait that enforces only the
must not contain any uninit (or padding) bytes
requirement. In particular, it should allow interior mutability. While I cannot think of any safe functions bytemuck could implement just with those guarantees, it is still a nice invariant to have. I am currently implementing multiple types that need this and am manually checking that there is no padding in there. Having it automatically checked via a derive macro similar toUninit
would be much less error-prone. Bytemuck seems like a natural place to put this, as it has other memory-related marker traits and there is probably a lot of overlap in the proc-macro functionality.