I really don't understand why one you want to come up with another name for Vector. This is the most apt name for this structure and anything else just muddles the field. Also, just because people coming from different languages would make different assumptions is neither here nor there. We should name things that work for Swift and let other languages worry about their ecosystems.
6 Likes
I'll throw in Repeat as well as another term that came to mind while I was eating dinner 
Example: Repeat<5, UInt16> - a repeat of UInt16, 5 times.
I'm otherwise also in favor of Inline as it plainly describes what is going on and how the type is intended to be used, though basically anything at that point is inline... It also suggests that Inline<1, T>, (T), and T are all equivalent, which as I understand it won't be the case.
2 Likes
The noun âmultipleâ refers to a number, as in â20 is a multiple of 5â. In the context âmultiple floatsâ itâs an adjective.
About the name, I have to agree with Les, it seems strange to spend so much energy on naming a vector type something other than âVectorâ or âVecâ.
4 Likes
I know. 
Just sayin' though. Although even as an adjective, I do think it would be applicable (if the community were so inclined) to make it an honourary noun like we have with Optional.
As I think a few folks have noted, the problem with Vector is that it is ambiguous or overloaded in existing usage, not that it is inaccurate. (But I don't want to speak for anybody else here.)
2 Likes
Unfortunately, none of the given alternatives have been better names than Vector despite the ambiguity. Especially with Buffer off the table.
Most vector math is either going to be done on Array or something like a struct Vec4 { var values: Vector<4, Float32> } anyway, so the confusion is likely to be mild. Especially if we conditionally add vector math operations to Vector when the types line up.
7 Likes
Because âvectorâ, for better or worse, is an extremely well established term thanks to C++, and it means the exact opposite of whatâs being proposed here. C++ interop is a major part of Swiftâs story as a C++ successor language, and the proposal in its current form would lead to the following confusing scenario:
// C++
template<unsigned len>
struct OID {
unsigned nodes_array[len];
using NodesVector = std::vector<unsigned>;
NodesVector as_vector();
};
// Swift
struct OID<let len: UInt> {
Vector<len, UInt> nodes_array; // why is this called âarrayâ?
func as_vector() -> NodesVector // does not return a vector!
}
Imagine if Swift 1.0 had reused the term âselectorâ for something completely unrelated to ObjC selectors!
Furthermore, I reiterate my point above: Vector does not help you understand when or how to use the type. Currency types donât need this extra justification, but thereâs disagreement even among the core team about whether this is a currency type. Inline makes it much clearer that this type serves a specific purpose and has potential performance implications for the calling convention.
4 Likes
The term "inline" is already used pervasively in Swift to mean something else.
And if the crux of the argument is that we wouldn't want Swift to have what comes across as "odd" naming as compared to languages with which it interops, naming the fixed-size array type Inline is certainly not going to help matters...
7 Likes
I would argue that the contextual site where it would be used does matter greatly, I donât think inline as a type used when defining properties would easily be confused with inlining of functions which is also (like this inline storage) an expert level feature.
(And itâs not the crux of my argument at least, I agreed with Karlâs reflection on naming and just thought Inline would be a great improvement which would be much more easily understood and reflect the inline storage nature of this type. A reason why people argue over naming is not just bikeshedding, it is also important for understanding - I do think -inline of Multiple would be more understandable and analogous to Optional - vector is as many already have pointed out way more overloaded in expectations (c++, graphics, math, âŠ))
Also:
The term "inline" is already used pervasively in Swift to mean something else.
Would then this rule out all the InlineXXX types above that was suggested as future continuations as they then would be confusing?
1 Like
Unfortunately or fortunately, depending on how you look at it, there are a great many places where types can appear that don't look like property type annotations.
If this type is named Inline, then it can be referred to without reference to the generic element in a number of contexts, including extension Inline { ... }. Likewise, it would cause collisions with any macro, property wrapper, etc. that would potentially be reasonably named @Inline.
I think it's reasonable to view a downside of "vector" being that it is overloaded in meaning in other programming languages or fields, but it does not seem like progress then to propose a name that overloads the meaning of a term that's already used in this programming language.
Maybe, maybe not? These types are not being pitched and certainly not under those names.
4 Likes
This discussion in getting really long with people proposing many new names. Could someone perhaps reiterate the points against FixedArray / FixedSizeArray people made upthread?
5 Likes
Karoy wrote about this at some length upthread, but the short version is that it is simply not an array. You can append to an array, or remove an element. You cannot do these things with Vector.
The key feature is its fixed-sizedness. It is really the unique fixed-size container; any other fixed-size container is just Vector with spicy indexing. This is why FixedSizeX isnât a great name; it implies that FixedSizeY should be a thing too, and it isnât.
19 Likes
Iâll put a vote in for Vector, despite the potential conflicts in usage, which I donât think end up being a big deal in practice.
And that is after a considerable amount of thinking about other names. One recent possibility was InlineVector, which fits in with the other members in the hinted family of Inline⊠structures⊠but it begs the question: if this is an inline Vector, what is the non inline version that it is an Inline version of? Iâm not sure thatâs entirely disqualifying, but it gives me pause.
6 Likes
Karoy wrote about this at some length upthread, but the short version is that it is simply not an array. You can append to an array, or remove an element. You cannot do these things with Vector.
Whether an array is something that you can append to or remove from is just a choice: it's really dependant on the language. Some allow this, others don't.
However, the proposed type has many properties typically associated with arrays: it's a collection, the sequence of elements matters and it has random access in constant time (differentiating it from a linked list).
So, do I know how to call this type? No.
But I will circle back to the start of this topic where the pitches' author felt they needed to add 'a fixed-size array' to the title of the topic to clarify what it's about. To me this is an indicator that:
a. 'Vector' wasn't self explanatory enough;
b. 'FixedSizeArray' or 'FixedArray' isn't such a bad name after all.
5 Likes
This is not a mathematical vector, nor a dynamically sized array like in C++ or Rust.
In my opinion, something like FixedArray, FixedCountArray, RigidArray, StaticCountArray or ConstantCountArray would be much more descriptive of what this type is.
Vector<Width, Scalar> would have been a good name for the SIMD2/3/4/8/16/32/64<Scalar> types had the integer generic parameters existed back in the day.
1 Like
I think that if we were interested in adding heavier math concepts to the standard library then Vector would be a protocol.
1 Like
I also don't understand this concern. Using XArray as the name doesn't imply that it will have all the same properties as an Array any more than StaticString implies it has all the same properties as String. It's a different name so it means something different. If the key feature is its fixed-sizedness, then the name seems rather obvious: FixedArray.
This seems like an odd concern for a language designer as, put another way, it's saying users shouldn't be able to infer functionality based on naming, which is usually what good languages want. And in any case, your should here is too strong a claim. What it actually implies is that, if the user sees FixedSizeY, it would have similar properties to FixedSizeArray. And sure, it gives the user a place to start looking for FixedSizeSet and FixedSizeDictionary, but that's a good thing, just like the existence of Set helps find OrderedSet (if the user knows about swift-collections at least).
(While you could implement those types as simply aliases for Vector, it doesn't seem like doing so would actually have the properties people expect, namely 0(1) lookup. So while it may sound clever to say that fixed size types are just Vector with spicy indexing, I'm not sure that's actually true, and it certainly wouldn't be most users first instinct. If, in the future, the lack of a FixedSizeSet (as a random example) is justified simply because "users could just wrap Vector", that's a bad thing.)
Vector is too easily confused with existing types and concepts to be a good name. If I have to point to this thread every time some junior engineer asks why it's named that way, it's not a good name. The simple fact that this thread's title had to clarify what Vector meant means it's not a good name. It's not a good name.
12 Likes
I'm in favor of this pitch. I don't have anything to add to the discussion about the API itself, minor nits I had have already been mentioned and addressed. I'm also very happy that it includes an upcoming feature that allows importing C arrays as Vectors.
My thoughts on the name `Vector`
I like Vector as the name. It is concise and to the point and I would expect to get used to it pretty quickly.
I think the various objections are understandable but my personal feeling is that they wouldn't be a huge issue in practice. Someone new to the language or type might initially have to look at the documentation to check what it does but the same goes for almost everything. And the name Vector already very strongly hints in the right direction.
People coming from C++ or Rust already need to learn that what they are used to calling a Vector is called an Array in Swift so I don't think Vector existing in Swift makes this particularly more complicated.
I would expect most projects won't be importing or defining a separate Vector type. And those that are using a more domain specific Vector type will probably be fine with getting their domain specific version by default over Swift.Vector. I'm not sure there would be many projects that heavily use both and would be forced to disambiguate constantly.
Non of the other suggested names have particularly swayed me so far.
HomogeneousTupleis apt but too much of a mouthful for something so fundamental.- I find the argument compelling that
Fixed(Size)Array,InlineArray, and other related names would be indicative of an array of fixed capacity but not count and that this type should have a different name. - Plain
Inlinefocuses too much on one particular aspect of the type and is IMO less clear at first glance. I feel the generic arguments inInline<4, Int>are almost more expressive of what it is than the name itself. Multipleand similar names are IMO the best of these alternate suggestions. They generally give a rough idea of what this type is about. But they are also fairly vague and I could imagine many different implementations of a type just from looking at the name, depending on the domain or library it would come from. They could just as well be Combine publishers than a fundamental data structure at a glance.Vectoris preferable to me since it only evokes a relatively narrow and related set of implementations.
TLDR: I like Vector as the name but I don't think I have anything new to add to the discussion really.
4 Likes
I think it makes sense to use a derived name when the new type is a slight modification of the concept, without challenging the core properties of the original type. StaticString is just a string known at compile time. This type still fits into most people's definition of what a string is. Remove an important enough property of String, and you get a completely different name, like Character (no longer a collection, but a single extended grapheme cluster) or ContiguousArray<CChar> (a collection of UTF8 characters instead of a collection of extended grapheme clusters).
So the question would be, is the ability of Arrays to grow a foundational part of what an "array" is in Swift? Or is it just a mere detail of the Array type in particular?
Several places in the documentation mention "array" (with a lowercase 'a') being a variable-size collection. To me this is a sign that the concept of array in Swift (and not the specific type Array) has been tied to it being a growable collection.
Plus, there's a huge pile of documentation that associates specific behaviors to "arrays" (like copy on write, heap allocation...) that wouldn't be true for FixedArray, simply because despite the superficial similarity, it's a fundamentally different type. Going beyond the state of the documentation today, one would always have to second-guess any statement of the form "arrays in Swift do X and Y..." (does it refer to arrays in general? or just Array?). The naming Vector would immediately address that uncertainty: Vectors are obviously not arrays. To this point, other languages seem to agree that these are different enough to warrant different names (even though C++/Rust had the names swapped).
FWIW, Rust's official documentation for array also has to clarify that it's a fixed-size array on the very first line. Similarly Rust's Vec also compares to array on its documentation (A contiguous growable array type [...]). It's not unreasonable to refer to other similar concepts when introducing a new concept. That doesn't mean that the explanation should be part of the name, otherwise dictionary-definition names would always prevail.
12 Likes
It is in fact a vector, vectors don't have to come with a vector space, in the broadest sense it's just a non-scalar quantity.
4 Likes
Some of the recent comments have been asserting that Vector will not be a confusing name to people who use the type, and I want to clarify that I fully agree with this, and that my primary hesitation about the name is something different.
My concern has not been that Vector will be hard to mind-map - I agree that it would be easy to learn once about the characteristics of the type, and from then on it would be easy to see Vector written in code and remember what those characteristics are.
Due to the shadowing behaviors in Swift I am not even worried that domain specific code that defines its own Vector type would suffer due to the existence of Swift.Vector.
My concern has been related to this statement I made above:
I am only thinking about the fact that if we define Vector in the way proposed here then we are shutting the door on more conceptually proper treatments of deep math concepts within the standard library.
It may be the case though that there are already aspects of the language that have shut that door long ago, permanently relegating those kinds of math concepts to packages, meaning that we don't need to worry about using up the name Vector in the standard library.
Can any member of the core team provide assurance that the standard library will never want to include math concepts like vectors in a more conceptually correct way?
(Or maybe someone else can prove that this ship has already sailed due to some other aspect of the language, and that we can give up on worrying about pristine math concepts existing in the standard library)
3 Likes