But it disagrees with all past use of the name “vector” in mathematics and numerical computing, which is reasonably consistent and well defined and dates from the mid-19th century.
I think it agrees pretty well with the mathematical definition, it's just a slight generalization.
A Rust (C++, etc) Vec<T> of length n where T implements addition and multiplication in a way that satisfies field laws is the "reasonable" representation of a n length "mathematical" vector over the field T. It just generalizes that storage type to situations where T is not a field.
It doesn't support addition of two vectors and multiplication by a element of T using the normal mathematical syntax, but that's a fairly reasonable choice given how we regularly use vectors as a sequence of independent numbers and the different priorities for math syntax and programming language syntax.
What makes a C++/Rust/etc vector distinct from an array is that it's resizable. That is its defining property.
On the other hand, a mathematical vector is not a resizable thing: a vector in R² is of a fundamentally different type from a vector in R³.
A type named "vector" should be more like Vec<T, n> for some type T and some integer n. Failing that, the reasonable representation of an n-length mathematical vector, in C++/whatever, is an array.
The whole idea of mutation is not common in mathematics, so of course mathematical vectors don't commonly resize.
The idea of appending an element to make a new vector is however extremely common, particularly in induction like proofs.
Vec<T, n> is in a sense already what we have, it's just that we are not capable of storing the n in the type information^0 so we store it at runtime.
^0 For a number of reasons. n can change with mutation while types can't. We don't necessarily know n ahead of time when building a vector (which happens in math too) but we have to know types at compile time. And we just don't have a great way of storing numbers in types in Rust anyways.
Just to clarify, a vector space is defined over a field but vectors themselves do not form a field.
Also more importantly in mathematics vectors aren’t really growable. When you change the number of elements you change the dimension (and thus the “type” for that vector). It is then ill-defined to add two vectors of different dimensions.
This is quite standard in the functional programming world; Common LISP, Scala, and Haskell all use "vector" to refer to (usually growable) contiguous-memory arrays with efficient random access, as opposed to "lists" with efficient append and prepend but inefficient random access.
I might be nitpicking but in Haskell and typical lisps “lists” don’t have efficient append. They are basically singly linked lists. A structure with efficient append and prepend (sometimes called a deque) is implemented as a finger tree in Haskell (with logarithmic random access), and as a vector of arrays in C++ (constant random access).
But it disagrees with all past use of the name “vector” in mathematics and numerical computing, which is reasonably consistent and well defined and dates from the mid-19th century.