It's an owned growable resizeable buffer, in contrast to the statically sized array [T; N] and the (dynamically) fixed-size slice [T]. Arr would cause confusion about this point.
Merits of the name "vector" aside, it's so established at this point that I don't think there will be any movement to replace it. The confusion with mathematical vectors is unfortunate but not terrible.
While I'm not a huge fan of the name “Vec,” it's about six years too late to make a change like this. Changes to stable APIs must have very strong benefits in order to be worth the churn they cause. The bar for such things is very high. And the old name would live on for years in existing code, tutorials, forum posts, etc., so anyone learning Rust would need to learn both names anyways.
But Arr<T> is a terrible name, too! In Rust an Array is a piece of sequential memory which can contain a fixed number of items, where that number is known at compile time. A Vec's length is only known at runtime and can be resized as needed. Using Arr<T> for growable arrays with our existing Array nomenclature would be just as confusing given fixed-size arrays have very different constraints and behaviour to a Vec<T>.
If you feel it is important you can always define pub type Arr<T> = Vec<T> at the root of your crate and use it by that name.
We wouldn't change the name of Vec<T> in the standard library though, that ship has well and truly sailed.
I'd be interested to know why Stepanov considers the name Vector to be a mistake. "Vector" fits well enough with my experience outside of computing.
Wikipedia says:
In physics, as well as mathematics, a vector is often identified with a tuple of components, or list of numbers, that act as scalar coefficients for a set of basis vector
Where "tuple" is:
In tuple is a finite ordered list (sequence) of elements
The key word there for me is "list". Sounds like a C++/Rust "vector" does it not?
Mistake or not I think using the terminology familiar from C++ and other languages is probably a good idea.
Certainly "Arr" would be awful. Just imagine people saying that all the time.
Well, as other people in this thread have said, a fundamental property of Vec<T> is that its length can change dynamically. Not only are the mathematician's vectors always immutable, they generally have a fixed dimension as well, which is the length of their representation (relative to a basis) as a list of scalars. (Technically dimension is a property of vector spaces and not of vectors: you can have a vector x contained in a two-dimensional space W, which is a subspace of a three-dimensional space V, so that x has "dimension" 2 or 3 depending on your perspective. But nothing about x is changing here.)
This quote says that a vector is a linear combination of basis vectors multiplied by scalars (elements of a field). That's the thing: the most basic operations on mathematical vectors is adding them and multiplying them by a scalar. Vec and C++ vector don't provide such operations. C++ valarray is a closer match to mathematical vectors.
I will grant you that vectors in C++/Rust etc don't meet the stringent definitions of mathematics.
But so what?
If we are going to go down that road we have to revise the entire Rust language. Never mind the name of a library construct.
Lets starts with the "=". What is that?
In mathematics that equals symbol means (wikipedia):
In mathematics, equality is a relationship between two quantities or, more generally two mathematical expressions, asserting that the quantities have the same value, or that the expressions represent the same mathematical object. The equality between A and B is written A = B , and pronounced A equals B .[1][2] The symbol "=" is called an "equals sign". Two objects that are not equal are said to be distinct .
The equals sign there is a statement of fact about the two quantities.
That is not what the equals sign means in Rust. Or most other programming languages. Where it is use for:
a) Moving a value from one thing to another.
b) Asking the question "are they of equal value"
We are going to have to use something other than "+", "-", "*", "/" as well. Given that they don't meet the requirements of their use in mathematics.
My son was a math major in college. He called me the first day of his intro to programming class (C++ if you can believe it) and asked me, "x = x +1; What's up with that?" I replied, "Programming ain't math."
As a math major (differential topology) who was a computer scientist for his entire professional career, I have to agree. Math is descriptive; programming is imperative.
That reminded me of when I was in school and me and a friend saw a snippet of python code somewhere. We laughed at it and said programming is dumb because "x can't be equal to x plus one, that's just stupid."
As another CS + Math person, I ... actually don't agree, though I can see these sentiments serving as some sort of first-order approximation intended get early students out of a certain mode of thought. The field of programming language principles/semantics lays the mathematical foundation to interpret programming as math, though various notions like variables take on a slightly different meaning in more imperative contexts. Though, if you're doing Haskell, you might not even notice a difference!
Really, the principal issue with x = x+1 is that the person who was confused interpreted it as x == x + 1, which (at least for integers) we would balk at just as easily as they did. Honestly, we're just too acclimated to x = x+1 meaning x ← x+1 that it simply doesn't faze us.
I think we should put Haskell aside in this discission. As far as I can tell Haskell is a serious attempt to "do maths" in a programming language correctly.
The obvious confusion is that for the average person with high school maths under his belt "x = y" is a statement about the value of x being equal to the value of y. As such it is either true or false. As an operator then in is a test for equality and the result is boolean.
Conversely in C and other languages "x = y" is an assignment of the value of y to x. Not the same thing at all.
Of course it was not always so that program language designers were so sloppy. In ALGOL, Ada, Pascal, Modula, the assignment operator is ":=", exactly to avoid this confusion. In VHDL it is "<="
Just to note "prior art", C# have indeed chosen to name the dynamically resizable buffer List<T>, which is definitely a better description of what this is, and array is the fixed-size buffer, like in Rust. The downside is the confusion with linked list. In Java they have, for this reason, ArrayList<T> (as opposed to LinkedList<T>). This is though a bit verbose.
I would indeed prefer <- or := rather than = for mutable assignment. But at least that's a deliberate trade somebody made for a reason (there is no good single ASCII character for this).
Whereas there is no real rationale for "vector" meaning dynamic array other than people got used to it in C++ (and now Rust), so it's a bit unfortunate because it was a chance to start fresh and drop that bit of legacy C++ baggage.
I understand that Arr wouldn't convey the dynamic aspect, but not sure if that's really a deal breaker. After all, "str" and "String" have some different properties too and are both called strings. And sure, pronunciation sounds pirate, but pronouncing Rc is even harder.
But there are plenty of other options, Arr was really an example proposal. I didn't really expect this to go through. If people actually wanted to change it, I'm sure there'd be a long discussion and somebody would have come up with a better proposal.
I have done a bit more historical research and I believe the origin of the name "vector" for arrays is in Lisp.
Perversely, in Lisp the command "vector" creates a fixed-sized array, while if you want to make a dynamically resizable one you use a more general "make-array".