-
Notifications
You must be signed in to change notification settings - Fork 45
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
Safe transmuting for Complex<T>
with bytemuck
#99
Comments
I'm fine with this, preferably as manual impls rather than derives to keep the dependencies down. It will need both |
Ok great. I can make a PR |
100: Add support for `bytemuck` traits r=cuviper a=bradleyharden `bytemuck` seems to be the *de facto* standard crate for safe transmuting. Because `Complex<T>` is `repr(C)`, it would satisfy the requirements for `Zeroable` and `Pod`, as long as `T` satisfies them as well. Add optional implemenations of `Zeroable` and `Pod`, gated behind the `bytemuck` feature. Closes #99 Co-authored-by: Bradley Harden <bradleyharden@gmail.com> Co-authored-by: Josh Stone <cuviper@gmail.com>
I think this request is unlikely to be accepted, but I thought I would at least ask.
I recently ran into an issue using
Complex<T>
with types from thefixed
crate andbytemuck
.fixed
implementsPod
, for all of its types, so they are safely transmutable to[u8]
slices. Unfortunately, once I useComplex
, I can no longer usebytemuck
, even thoughComplex
would satisfy theunsafe
requirements ofPod
.I was wondering if it would be possible to add
bytemuck
as an optional dependency, with an implementation ofPod
forComplex<T> where T: Pod
.bytemuck
seems to be stable and the de facto standard crate for safe transmuting.I think this would also address the request in rust-num/num#408.
The text was updated successfully, but these errors were encountered: