Computing has an extremely long tradition of using "vector" in a generalized way, meaning finite sequences of a fixed length. Stepanov did not pull the name std::vector out of thin air -- by the 90s, this word has been thoroughly generalized to cover more than just sequences of "numbers".
(What sort of numbers, by the way? If we insist on the classic vector space definition, there can be no such thing as a vector of integers.)
As is well-documented, Stepanov considers the name of std::vector to be a mistake, but not because it can contain things other than scalars -- it's a mistake because std::vector is dynamically resizing, and as such, it should've been called std::array. That name was later used to label their construct that models C arrays, i.e., actual vectors.
Here is a random collection of quotes I found on my bookshelf, of the term "vector" being used to name the idea of a sequence of elements of a specific size" . They're mostly from editions published in the 90s or later, but the convention goes waaay back. (Apologies, I'm much too young to have 1st editions of these.
"To model computer memory, we use a new kind of data structure called a vector . Abstractly, a vector is a compound data object whose individual elements can be accessed by means of an integer index in an amount of time that is independent of the index." -- H. Abelson, G. J. Sussman, Structure and Interpretation of Computer Programs (MIT Press, 2nd ed, 1996)
"Vectors, see Linear lists." -- D. E. Knuth, The Art of Computing Programming, vol 1. (AddisonâWesley, 3rd ed, 1997)
"The standard example is the type of lists of specified length, traditionally called vectors. We fix a parameter type A, and define a type family Vecn(A), for n : â, generated by the following constructors:
- a vector nil : Vec0(A) of length zero,
- a function cons : â(n:â)A â Vecn(A) â Vecsucc(n)(A).
In contrast to lists, vectors (with elements from a fixed type A) form a family of types indexed by their length."
-- The Univalent Foundations Program, Homotopy Type Theory: Univalent Foundations of Mathematics (2013)
"To write a total function first, we must use a more specific type constructor than List. This more specific type constructor is called Vec, which is short for "vector," but it is really just a list with a length.
An expression (Vec E k) is a type when E is a type and k is a Nat. The Nat gives the length of the list.
-- D. P. Friedman. D. T. Christiansen, The Little Typer (MIT Press, 2018)
My current library is particularly lacking in classic works on type theory or formal semantics, which is why my type theory quotes are so recent. For what it's worth, my own formal training was based on classic Floyd-Hoare logic, and I can remember plenty of use of "vector" that goes well beyond tuples-of-"numbers". I can find examples of Floyd using it in this sense even as early as the sixties.
"Boldface letters will designate vectors formed in the natural way from the entities designated by the corresponding nonboldface letters: for example, P represents (P1 P2, â˘â˘ Pk).
-- Floyd, R. W., âAssigning meanings to programs,â Proceedings of Symposia in Applied Mathematics Vol. 19 (1967), pp. 19-32.
We've had generations of programmers growing up on (at least some of) these; I am very much one of them.
The use of the name Vector in the sense we're proposing is not a novel invention. It is not in any way a radical new abstraction. We are not breaking new ground. We are merely following a very much well-established tradition.
At the same time, it can also be true that words mean different things to different people. After all, no two people speak the same language; communication is lossy at best.
There are plenty of examples of people using "vector" to mean heterogeneous lists (as was often the case when people talk about "state vectors"), people talking about infinite vectors, people insisting that "vectors" are dynamically resizing arrays, that "vector" is a specialized SIMD construct, that "vector" is a list of numerical data, that "vector" is a direction and a length.
Names aren't context-free. They do not have universal meanings, just vibes. As humans, we have the capacity to make abstractions, to recognize patterns, to generalize preexisting concepts. We routinely make use of this in everything we do, and we are plenty capable of dealing with context and nuance.
Our job is to come up with a term for this new type. Above all else, the new name must not mess up the existing nomenclature of Swift -- words do have concrete meanings in this context, and we must not dilute that.
The proposed type will generally be used as an alternative for homogeneous tuples. But using the word Tuple in the type name would be confusing; that name is already taken to mean a specific construct in Swift, and while this new type is similar to that, it is not the same. We need to be able to clearly distinguish between the two, in writing as well as in oral communication.
Similarly, the new type is like a fixed-count array, but is certainly not an array type in the sense that we use that term in Swift. Our arrays come with resizing operations like append or remove; they can be concatenated to form new arrays, with the result having the same type as the input. This new type has no such operations. We have never used the word Array to name a type like that in Swift, and we should not start now. We're on the verge of proposing multiple new array variants; sticking to our established terminology is going to be crucial to avoid confusion.
Therefore, I am in vehement opposition to the idea of calling the new type a Tuple or an Array. In the context of Swift, this is not a tuple type. In the context of Swift, this is not an array.
We must use a name that's distinct from those.
We chose to propose the name Vector, as it was by far the most obvious choice. "Vector" is already in widespread use in a meaning that precisely matches our construct -- it usually denotes a finite sequence of items, with a fixed length that is part of the type. Vector obviously has the correct vibes, and there is ample of precedent of prior usage in our precursors. Even the ill-chosen name std::vector in C++ puts people in the right ballpark -- it names a linear container with integer indices. I therefore find the worry about "confusion" a bit of a stretch. We can also mitigate it by choosing to truncate Vector to Vect or Vec, like we've done with Int, Bool. (Yes, I'm well aware Rust calls its array type Vec. I am trying really hard to find a reason to care, to no avail.)
Some folks evidently believe that a type called "vector" must be a "mathematical" vector (whatever that means; definitions vary wildly). On the other hand, some folks appear to believe that "vector" must mean a dynamically resizing array type, or legions of C++ survivors will not feel adequately welcome to Swift. I do find these arguments tiresome -- it is well within our power to define what Vector should mean in Swift, and for where I'm standing, our proposed definition is clearly close enough to both of these meanings.
But as long as we do not try to mislabel this type as an "array" or "tuple", we still have plenty of options to name it, even if we discard "vector" -- we just need to pull something out of thin air that has the right vibes.
Collective nouns or terms for containers are great options. Our universally established computing terms for "array", "stack", "heap", "collection", "set" have already borrowed from this same space, with great results.
We've seen many suggestions for such names in this thread; I've curated a collection of highlights below:
@clayellis suggests Cluster, Batch, Bunch, Grouping, Group, Lot, Clump
@jberry suggests Slab
@Sajjon suggests Row, Rack, Cabinet, Cubby, Hive, PeaPod
@JanWillemBrands offers Bunch
I recommend Run, Spread, or Pack myself.
I do think that collective nouns generally work great for this purpose. Flock, Fleet, Pile, Wad, Bouquet would also all be lovely choices. I find expressions like "a bouquet of four integers" or a "pod of six booleans" or a "flock of doubles" rather charming, and it would tickle me to name this type like that.
In my everyday conversations, the word "pack" has recently gained some notable traction as a naming alternative. Pack<4, Int> looks and sounds great; however, it does have the drawback that SE-0393 has established the terms "parameter pack", "type pack", "pack expansion" etc. to mean related-but-different concepts. The argument I'm using to rule out Tuple therefore also applies to Pack -- however, I feel the association may be less strong in this case, and so there may be a chance we can use it anyway.
If we consider Pack to be already taken, then I offer Pod, from @Sajjon's "PeaPod":
struct Pod<let count: Int, Element: ~Copyable> { ... }
extension Pod: Copyable /* where Element: Copyable */ {}
var x: Pod = [1, 2, 3]
func foo(_ items: Pod<3, Float>) -> Int
Note that unlike Vector, none of these terms have any established use in this context -- we're conjuring these from thin air, and whatever name we invent will be equally foreign to all programmers, no matter their background. This makes them a lesser choice in my eyes, but if Vector is off the table, then these seem the least harmful choices. They are memorable, they roll off the tongue, their everyday meaning is a good fit with our proposed use, and they do not mess up Swift's preexisting terminology.