yoanlcq
commented
2 hours ago Thanks for reporting this.
I could probably write an essay about how much I hate this change, but what really matters are the actions I take.
My knee jerk reaction is : at this point the most sensible thing to do is for vek to drop repr_simd support. What's the point anymore? std::simd::f32x4 and friends seem to be the way forward.
So you'd use vek's repr_c vectors for general gameplay code, and as soon as you need really performance-critical batch calculations, you go all in with arrays of f32x4 and clever specialized code.
To be fair, this has always been the way to go in C/C++.
And that's it. The alternative ("solution 2") is to still support repr_simd but replace members by a single array only for these, and state clearly that they can't act as a drop-in replacement for repr_c types anymore. People would still be able to convert between these two repr if they like; that, or they replace their uses of the x, y, z, w members.
Your proposal to remove repr_simd from default features is a good idea. It's the least I can do.
But man... This is going to be a pain. Granted, we're in unstable territory, but it's still something that's suddenly coming up out of nowhere to eat my time, and there's nothing in it for me. Just a free waste of time. Gotta love it
The feature
repr_simdno longer supports structs with multiple fields.The fix is to convert vek's vectors to use arrays internally. I haven't looked at how much work it would be.
The workaround is to disable vek's default features and only use the ones you need - e.g.
vek = { version = "0.17.0", default-features = false, features = ["rgba", "rgb", "std"] }.I propose that a quick temporary solution would be to publish 0.17.1 with
repr_simdremoved from the list of default features.