Skip to content
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

Closed
bradleyharden opened this issue Jan 28, 2022 · 2 comments · Fixed by #100
Closed

Safe transmuting for Complex<T> with bytemuck #99

bradleyharden opened this issue Jan 28, 2022 · 2 comments · Fixed by #100

Comments

@bradleyharden
Copy link
Contributor

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 the fixed crate and bytemuck. fixed implements Pod, for all of its types, so they are safely transmutable to [u8] slices. Unfortunately, once I use Complex, I can no longer use bytemuck, even though Complex would satisfy the unsafe requirements of Pod.

I was wondering if it would be possible to add bytemuck as an optional dependency, with an implementation of Pod for Complex<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.

@cuviper
Copy link
Member

cuviper commented Jan 29, 2022

was wondering if it would be possible to add bytemuck as an optional dependency, with an implementation of Pod for Complex<T> where T: Pod. bytemuck seems to be stable and the de facto standard crate for safe transmuting.

I'm fine with this, preferably as manual impls rather than derives to keep the dependencies down. It will need both Pod and Zeroable, but they should be easy enough.

@cuviper cuviper transferred this issue from rust-num/num Jan 29, 2022
@bradleyharden
Copy link
Contributor Author

Ok great. I can make a PR

bors bot added a commit that referenced this issue Apr 29, 2022
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>
@bors bors bot closed this as completed in #100 Apr 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants