-
-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no-uninit trait with interior mutability #218
Comments
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 |
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.The text was updated successfully, but these errors were encountered: