4 ms·

Hey Steve, Who do we have to harangue to get Rust to rename "Vector"? It is kind of embarrassing and confusing terminology, and there is no reason to propagate

by jblow 12y ago

Hey Steve, Who do we have to harangue to get Rust to rename "Vector"? It is kind of embarrassing and confusing terminology, and there is no reason to propagate it. Just call an array an array and an immutable array an immutable array. There's no good reason to perpetuate the mistakes of the C++ people. (Note to those not understanding the objection: A vector is defined an element of a group that is closed under addition and multiplication. This is a very specific and very widely-useful meaning, and any program that does stuff with math is going to use vectors. So when you come along and put into your standard the idea that 'vector' means an arbitrary collection of elements that probably are not even scalars, you not only show that you don't know what vector means, but you confuse the programs of many many of your users, because now they have two totally different things both of which are called Vector and that are both used very heavily. [There is no way in hell anyone is going to call a math vector anything but vector, since that would be insanely confusing.])

lambda 12y ago
My understanding is that in order to make a proposal like this (any change to the syntax or semantics of the language or standard library), the way to advocate a change is to write an RFC. To do so, you fork the rfcs repo on GitHub (https://github.com/rust-lang/rfcs https://github.com/rust-lang/rfcs), and write a document describing your proposal and its pros and cons. Then the community can discuss it, and if there's sufficient interest someone will champion for it a shepherd it through the RFC process.
steveklabnik 12y ago
Short because I'm on my phone: my sibling is correct. But I think it's important to understand that Vec<T>, [T, ..N], and &[T] (vectors, arrays, and array slices) aren't different because of mutability. The differences are in ownership, growability, and where the backing memory is allocated. Also, Vec<T> isn't part of the language, but part of the standard library, while the other two are language items. Any RFC would have to take this into account.
- ecl3ctic 12y ago
  I know you're not exactly opposing the above comment, but I'll make a supporting argument here which acknowledges what you've said: I feel as though we can retain understanding of those differences without using the name "Vec", which can be considered a poor choice for the reasons mentioned above (by C++ and Rust alike). Array<T> for a growable array [T, ..N] for a fixed-length array &[T] for a slice into either of these array types Even forgetting the mathematical concept, I would argue that throwing the term "Vector" into the mix only makes things more complicated than they need to be, since sticking to "Array" homogenizes everything. For good reason, we don't call a resizable string a "Hobnob" in an attempt to disambiguate, so why call a resizable array a "Vector", which makes just as much sense?

by jblow 12y ago

lambda 12y ago

My understanding is that in order to make a proposal like this (any change to the syntax or semantics of the language or standard library), the way to advocate a change is to write an RFC. To do so, you fork the rfcs repo on GitHub (https://github.com/rust-lang/rfcs https://github.com/rust-lang/rfcs), and write a document describing your proposal and its pros and cons. Then the community can discuss it, and if there's sufficient interest someone will champion for it a shepherd it through the RFC process.

steveklabnik 12y ago

Short because I'm on my phone: my sibling is correct. But I think it's important to understand that Vec<T>, [T, ..N], and &[T] (vectors, arrays, and array slices) aren't different because of mutability. The differences are in ownership, growability, and where the backing memory is allocated. Also, Vec<T> isn't part of the language, but part of the standard library, while the other two are language items. Any RFC would have to take this into account.

ecl3ctic 12y ago
I know you're not exactly opposing the above comment, but I'll make a supporting argument here which acknowledges what you've said: I feel as though we can retain understanding of those differences without using the name "Vec", which can be considered a poor choice for the reasons mentioned above (by C++ and Rust alike). Array<T> for a growable array [T, ..N] for a fixed-length array &[T] for a slice into either of these array types Even forgetting the mathematical concept, I would argue that throwing the term "Vector" into the mix only makes things more complicated than they need to be, since sticking to "Array" homogenizes everything. For good reason, we don't call a resizable string a "Hobnob" in an attempt to disambiguate, so why call a resizable array a "Vector", which makes just as much sense?