Cameron Hart

My read is that`Vec3A` is not eligible to be `Pod` in bytemuck due to padding at the end (because of alignment). Technically it would be eligible if simd is enabled...

The key part being > as long as all other rules end up being followed which includes > The type must not contain any padding bytes, either in the middle...

What specific optimizations are you referring to?

Generally with glam I have focussed on functionality that is in stable rust or have a clear path to stabilisation. These intrinsics are unstable and as far as I know...

It is something I've been wondering about, also in conjunction with adding an affine transform type. I don't think I've used a library that had a separate point type before....

I wanted to add a few more thoughts on this. I'd certainly be interested in trying out a point type to see how it feels and see how much churn...

The recent refactor moved the majority of the functionality into a core library which could be reused by a different high level interface. It's currently all internal, because I didn't...

I did want to provide something at least and in this case at the time I wrote this I didn't want to try provide a generic solution. The main reason...

This has been in the back of my mind for a while. I was thinking perhaps an approach would be to have a separate coordinate system crate. The idea wouldn't...

It's been a while since I looked at this code. But from what I can see the only places that realloc reassign the pointer and I don't believe anything points...