Closed marningmol closed 2 years ago
Sounds reasonable. The main constraint is that euclid makes a big effort to introduce API breaking changes as rarely as possible. So if bytemuck is to have breaking changes soon, euclid will stay with the older version for a while longer.
With that in mind we can add the feature now or wait if we suspect there'll be a better timing later.
Or, we can document that the bytemuck feature is not fully supported, that it will change without euclid semver bumps and that it's up to downstream project that opt into it to deal with the breakage (I don't like it but it's one way to get the feature earlier and if bytemuck is to stabilize later it can become more properly supported in euclid then).
Added in 0.22.7.
Most euclid types already satisfy Pod and Zeroable when their components do, they just need the traits added.
For such a generally used and useful crate as euclid it would be great to have the additional features provided by Pod and Zeroable as an optional feature.
https://docs.rs/bytemuck/