Standardize 2D/3D Vector / Coordinate Class

Question

Question
This is something that's bugging me for some time now, but I couldn't find a definitive answer for it:

• Is anyone aware of a proposal to introduce a standard 2D and/or 3D Vector (a struct with x,y and z members) to the STL?
• If not, is there a realistic way to get such a class into the next version of the standard - short of writing a complete and perfectly written proposal myself?
• And, are there any good reasons (aside from no one having the time) why this hasn't already been done?

I'm definitely willing to contribute, but I believe I lack the experience to produce something of high enough quality to get accepted (I'm not a professional programmer).

Reasoning / Background
By now I've seen dozens of libraries and frameworks (be it for graphics, physics, math, navigation, sensor fusion ...) which all basically implement their own version of

struct Vector2d {
    double x,y;
    //...
};
/* ...
 * operator overloads
 */

and/or its 3D equivalent - not to mention all the occasions, where I implemented one myself before I took the time to do a proper, reusable version.
Obviously, this is not something difficult and I'm not worrying about suboptimal implementations, but every time, I want to combine two libraries or reuse code from a different project, I have to take care of converting one version into the other (either by casting or - if possible - text replacement).

Now that the committee strives to significantly extend the standard library for c++17 (especially with a 2D graphics framework), I really would like to have a common 2D vector baked into all interfaces from the start, so I can just write e.g.:

drawLine(transformCoordinates(trackedObject1.estimatePos(),params), 
         transformCoordinates(trackedObject2.estimatePos(),params));

rather than

MyOwnVec2D t1{trackedObject1.estimatePosX(), trackedObject1.estPosY()};
MyOwnVec2D t2{trackedObject2.estimatePosX(), trackedObject2.estPosY()};

t1 = transformCoordinates(t1,params);
t2 = transformCoordinates(t2,params);

drawLine(t1.x,t1.y,t2.x,t2.y);

The example might be a little exaggerated, but I think it shows my point.

I'm aware of std::valarray, which already goes in the right direction, as it allows standard operations like addition and multiplication, but it carries far too much weight if all you need are two or three coordinates. I think a valarray, with fixed size and no dynamic memory allocation (e.g. based on std::array) would be an acceptable solution, especially as it would come with a trivial iterator implementation, but I personally would prefer a class with x, y (and z) members.

Remark: I'm sorry if this topic has already been discussed (and I would be surprised if it hasn't), but every time I'm searching for 2d vectors I get results talking about something like std::vector<std::vector<T>> or how to implement a certain transformation, but nothing on the topic of standardization.

Answer 1

are there any good reasons (aside from no one having the time) why this hasn't already been done?

There's essentially no reason to.

Forming a type that contains two or three elements is utterly trivial, and all the operations can be trivially defined too. Furthermore, the C++ standard library is not intended to be a general-purpose mathematical toolsuite: it makes sense to use specialised third-party libraries for that if you are serious about mathematical types and constructs beyond the functions and operators that you can throw together in half an hour.

And we do not standardise things that do not need to be standardised.

If C++ were to gain some kind of standardised 3D graphics API then I can see this changing but not until then. And hopefully C++ will never gain any kind of standardised 3D graphics API, because that is not what it is for.

However, if you feel strongly about it, you can start a conversation on std-discussion where all the experts (and some assuredly non-experts) live; sometimes such conversations lead to the formation of proposals, and it needn't necessarily be you who ends up writing it.