(T,T,T) vs [T,..3]


In rust we have 4 options for representing vector maths types:- (each has its own appeal)

(T,T,T,T)                // could switch to (X,Y,Z) for precision,Zero/One types
[T,..4]                  //indexable
struct Vec4(T,T,T,T)     //equally good for r,g,b,a x,y,z,w & nice constructor
struct Vec4{x:T,y:T,z:T,w:T}// most common choice

of course what i’ve currently done is wrapped all that in accessors, but it got me thinking about this.

(On IRC i’ve even seen a suggestion for struct Foo[T,…N] , which would bring it to 5… options)

Could this be simplified slightly, by considering tuples as the most fundamental type, and declaring that [T,…3] is just sugar for it-

  • Represent a tuple in the compiler as a vector of types and repeat-count of the last.

struct Foo[T,…N] drops out aswell.

auto-coerce: [T,…3] == (X,Y,Z) with X=Y=Z=T (T,T,T) == [T,…3]

support the index operator for any homogeneous tuple

Would this still fit with plans for ‘ints in type system’ to recover C++'s ability to make generic buffer sizes and so on

perhaps the square bracket constructor could also be freed in the syntax for something else more specific to slices/vectors … initialise a tuple with (…,…,…) which can also be treated as an array if its’ homogenous , whilst […] could be something more like std::initialiser list, or something we could overload to always create a Vec


This was an RFC that was postponed. https://github.com/rust-lang/rfcs/pull/104


ok good to see its not completely out of the question. the .0 .1… accessors are a neat idea too