Michael Kirk
Michael Kirk
> No, metadata (to be renamed per above) is not required for 3D, but seems to be requested enough (and common enough in the industry) to introduce at the same...
If releasing geo-types 0.7.4 solves this problem, that seems fine. It'd be good to have a release anyway, but I'm a little confused as to what the problem is. Typically...
@nyurik - I don't see where you've patched the WKT dependency. Are you intending that it use https://github.com/nyurik/wkt/tree/wkt-dim?
BTW if people are into this idea, I'm willing to do the grunt work. I should have time to complete it in the next several days.
Hiya @georust/core - this proposal to deprecate direct access to geo-type fields is likely to affect you. This is being done to soften the blow of an imminent breaking change...
> Does that not work with the ZM generics? It feels simpler to say coord.x = 10 than the mut methods I agree `cood.x = 10` is more concise. And...
> IMHO ZM coords is such a big and breaking change so it should be easy to spot / fix the error on upgrade I agree that it should be...
> nalgebra which also does a lot of generics magic still manages to expose field access (via some sophisticated DerefMut impls): So you get vec3.z, mat3.m11, vec2.x etc. I've been...
> move back to vanilla pub fields (but all 4 coords) in the next breaking release. Is that what your suggesting? I would actually suggest to keep the fields on...
> I don't know if there are any performance implications with repr(c) This is worth calling out. So long as all of our fields are the same size my understanding...