Add `Point` types?

[icefoxen]

nalgebra and cgmath both separate Point types from Vector types... a Point is a location, and a Vector is an offset from a location. Thus you can add together a Point and a Vector and get a new Point, or you can add two Vector's and get a new Vector, but you can't add together two Point's.

While this starts off weird, the distinction has grown on me a lot. Since the actual representation of a Point and a Vector are identical, as are many of the actual math operations on them, I totally understand if you don't want to do this, but I was wondering if you'd considered it.

[yoanlcq]

This is tricky as this kind of design decision is quite opinionated and is neither really "right" nor "wrong".

Well, my answer is "please no", and I'll try my best to justify it here. :) It's more for posterity than trying very hard to prove my point.

To start with, this falls into the category of "using the type system to enforce mathematical properties". Other examples that come to my mind (and are strictly equivalent to me) are :

• Deg/Rad types;
• Affine / Transform / Orthographic3 / Perspective3 in nalgebra;

These do a good job at making the API and client code more explicit and precise (hard to misunderstand what a Orthographic3 is) and "mathematically correct" at compile-time ("you fool, trying to add two Points together! Next thing you know we'll be able to divide by zero.").

However there are big deal breakers to me :

• There's a point at which they become noise. I want to add these two float pairs together, and I'll hate at anything that tries to stop me. My OpenGL shader doesn't care about my Orthographic3, it just wants a 4x4 matrix. I'd rather write cos(PI) than cos(Rad(PI)).
• It can only complicate APIs and the life of users. All of these types introduce their own sets of methods, mental overhead for newcomers that try to figure out how to convert from one type to another, etc. Sure, with e.g vek's Mat4, you don't get all of these mathematical properties made explicit by the type system, but at least the API is unified. A Mat4 is a "transform" if you want to see it like one. It is "affine" if you make it so. You can write functions that just take a Mat4 instead of searching for the best mathematically accurate trait bounds or whatever.
• These types are "lies" in that they "hide" the fact that the hardware has to deal with them (re: OOP vs Data-Oriented Design). CPUs and GPUs deal with "vector types" via "vector registers", they couldn't care less whether or not they are "points" or "vectors". One of vek's design goals is not to hide the truth of the hardware, hence the #[repr(simd)] versions for each type. Vec4 is intended to be viewed as a "hardware type". vek is intended as a "hardware lib" in that sense.
• It smells a lot like feature creep.
• GLSL does not distinguish point vs vector. Neither does GLM. Actually, neither does Unity. And neither does DirectXMath. Actually I do not know of any API that does this except in the Rust ecosystem.

That's pretty much it :)

[icefoxen]

Good reasons! Thanks for the explanation, it's a perfectly reasonable set of choices. I was just wondering what your thoughts were. :)