Vector, a fixed-size array

[lorentey (Karoy Lorentey)]

@Nobody1707

For what it's worth, I believe Hylo uses Buffer as the name for its fixed sized arrays.

"Buffer" is a great name. Unfortunately, the Swift Standard Library is already using it to mean a very different thing:

@lorentey

I don't think I've seen this spelt out anywhere, but the stdlib appears to consistently use the term "buffer" to mean a region of memory with unspecified (i.e., client-managed) initialization state. UnsafeBufferPointer and ManagedBuffer/ManagedBufferPointer do not (in general*) make type-level assumptions on which of their slots contain initialized values -- managing that is entirely outside their mandate, and they expect code that uses them to do custom bookkeeping to prevent misuse. This makes these constructs crucial for building efficient data structures (each of which come with well defined, but incompatible ways of performing that bookkeeping), but it also covers them in a thick layer of ambiguity and danger that makes it wildly inappropriate to use them as a way to exchange or transfer data. I look at the existing types as primarily useful for representing "storage", or data in stasis.

Vector is like a fixed-size array; it's like a homogeneous tuple; it's like a fully initialized buffer; it's like an escapable span that has its own inline storage. These are all valid ways to explain what it is; none of these phrases would work well as the name of the type.

@1-877-547-7272

It doesn’t conform to AdditiveArithmetic (even conditionally), even though an actual vector type would.

Nothing prevents us from adding a conditional AdditiveArithmetic conformance to Vector. We did consider adding this; we did not include it in the proposal, but there is nothing specifically preventing this later.

However, note that the stdlib's preexisting "actual" SIMD vector types (SIMD2, SIMD3, etc) also do not conform to that protocol. This strongly hints at an underlying issue.

I'd be particularly interested in seeing packages that experiment with implementing operators like + or * (for scaling with a scalar) to Vector. There is a real risk that Swift's expression checker is not strong enough to bear such load, and that the compiler will not emit well-optimized code for complex vector expressions -- it would be lovely if we figured out how to resolve these. This experimentation does not need to (and I believe it really should not) start with an evolution proposal.

@1-877-547-7272

It’s worth noting that in Swift, + is used both for addition and for concatenation . That means that if we were to add a + operator to Vector, then it would likely be pretty confusing.

This is a valid reason not to add a standard + operator. (However, note that we do not expect to ever offer an operation to concatenate two vectors -- that is not what vectors are for.)

(Reasonable people may also disagree on the meaning of *.)

However, this should not prevent packages from experimenting with adding + and * operators. It also does not prevent Vector from providing named methods for forming linear combinations.

@dimi

If we wanted to have fun and still wanted a one word name, I would suggest Shelf or Case — it ain’t growing in size, but it holds a fixed number of items.

@ibex10

Row or Store could be alternative type names to consider instead of Vector.

These are also great names. They come with a great disadvantage against Vector, though: they are brand new names, freshly invented with zero preexisting precedent (that I know of -- although "row" is being used in relational databases, in a context that has nothing to do with Vector.). I'd like us to keep them in mind for some actually novel use case in the future.

Even the most vehement critics of the name Vector must concede that it hints strongly at the nature of this type: indeed, while C++ mistakenly calls its array type std::vector, no actual person is ever seriously confused that we call our (much better) equivalent Array. Likewise, no actual person will ever be seriously confused if we called our (much better) std::array type Vector.

The STL's naming mistake simply reinforces the use of the term "vector" to mean a vaguely array-shaped thing.

@1-877-547-7272

If the standard library were to define a type named Vector, then that would cause a source break in any module that uses another module’s Vector type.

If this argument was valid, it would apply to every new type we ever add to the stdlib. Luckily, its premise isn't true -- names defined locally (or explicitly imported) shadow all names implicitly imported from the stdlib. Any preexisting (or future) local use of the Vector type name will continue to resolve to its local definition.

(We've gone through all this with Result.)

@1-877-547-7272

Additionally, it would discourage library authors in the future from creating their own types named Vector, even when that’s the best name for the type.

This is true, but I don't see how this is a negative thing -- part of the job of the Standard Library (of any language) is to establish great names for its fundamental primitives. The stdlib's names are huge part of what defines a language -- it defines the vocabulary of all Swift code.

From what I can tell, the type we're introducing is the best possible use of the name "vector". If someone finds another vector-shaped type, they are more than welcome to name it as such -- they just need to figure out a qualifier that distinguishes it from the stdlib's type.

The stdlib ships with a generic type called Set that is based on a very specific variant of hash tables. This is just one possible way to define a useful set, even if we assume that sets are based on hashing. The stdlib naming its type Set has indeed discouraged other people from using the name Set as is; but it has not prevented us from adding different (sometimes wildly different) set-like types -- we just tend to add qualifiers, like OrderedSet, TreeSet, or SortedSet.

The Standard Library shipping with a Vector type will likewise establish a clear direction for naming similar types. (If there are any; Vector is certainly going to be difficult to compete with on merits.)

@QuinceyMorris

"How about List?"

List is a great name. All previous usages of it that I've seen (and I've seen quite a lot of them) were resizable, like an array.

(There is also the very prominent usage of the name List in SwiftUI. Like it or not, it practically prevents us from ever using this name for a standard container type.)

@davedelong

I much prefer FixedArray.

That would imply there was something broken with Array. There isn't.

@Diggory

Total bikeshedding, but how about the name 'RigidArray'?

In some early drafts, that was indeed the working name for this type. We've moved on from it because we realized Vector isn't really an array variant. Early feedback also indicated that the adjective "rigid" has some negative connotations that we do not want to associate with Vector.

@rauhul

don't have a specific issue with the name Vector but I am curious what a future Fixed Capacity Array might be named, and similarly what names we might give other fixed collections, like {Stack|Queue|RingBuffer}<let Capacity: Int, Element> etc...

We now use the Rigid prefix as the provisional naming convention for the fixed-capacity, but heap allocated array, deque, set variants: RigidArray, RigidDeque, RigidSet, etc. (The negative connotations of rigidity are apt there, as these variants are rather annoying to use in practice.)