These would establish a precedent for a particular style of naming that personally I find distasteful. I'd much prefer not to end up being forced to say that this-or-that function should return an "inline" of four integers, or a "repeat" of six floats, or a "storage-of" of ten doubles.
These would be good names, if they weren't already taken to mean things different than the proposed Vector. Unfortunately Swift already uses these terms; hijacking them for the new type would lead to endless confusion.
(I've previously written about Tuple, Buffer. As James has noted, Block means a group of statements.)
To reiterate once again, the label "array" in Swift refers to a particular family of data structures. In the fullness of time, I expect the members of this family to be as follows:
Array<Element>- This is the preexisting, copyable, self-resizing, dynamically allocated array type that implements the copy-on-write optimization. It only supports copyable elements. It has built-in interoperability withNSArrayfrom Objective-C, leading to unpredictable performance.ContiguousArray<Element>-Arraywithout the Objective-C bits.InlineArray<count, Element>- Future conditionally copyable, fixed-capacity, nonresizable array type with inline storage.RigidArray<Element>- Future noncopyable, fixed-capacity, manually resizable, dynamically allocated array supporting noncopyable elements.DynamicArray<Element>- Future noncopyable, self-resizing, dynamically allocated array supporting noncopyable elements.SmallArray<inlineCapacity, Element>- Future noncopyable, self-resizing array type with built-in inline storage for a predetermined number of items, dynamically switching to heap allocations when necessary. (Effectively an enum ofInlineArrayandRigidArraycases, with extra logic to switch between them.)
(Of the four new types listed here, RigidArray and DynamicArray are currently within reach -- the primary blocker is that we cannot define subscript accessors with correct semantics, but that objection also applies to Vector and Span, so I suppose we can simply continue to pretend the problem does not exist, and instead keep having endlessly looping arguments about their names. InlineArray has more technical issues, as we haven't reached an agreement on how it (and types like it) will coordinate with the Swift runtime to tell it where their initialized elements are. Each of these potential new array types have important use cases; but which of these four (if any) we'll actually end up proposing to the stdlib is getting less clear to me with every post I read on this thread.)
All members of this family of types will provide the same operations; they all share largely similar performance characteristics; they have similar use cases.
The proposed Vector is not a member of this type family.
Vector belongs in the same loose type family as Span, UnsafeBufferPointer and UnsafeMutableBufferPointer. The upcoming MutableSpan will join the same category. None of these are array types, and none of them should be named as if they were.
These are great names. If we somehow end up choosing a name other than Vector,
I would be fine with either one of these. I'll throw in my own plan B, too, which is to call the type Run or Spread. (As in, "this function should return a run of 4 integers" or "that struct should store its contents as a spread of 8 floats".)
All of these suggestions suffer from the same fundamental issue -- we are pulling them out of our collective behinds, with zero regard to precedent and tradition.
The type we're proposing is not a novel invention; it isn't a radical new idea. It just reformulates a preexisting shape to fit Swift. The proposal simply chooses the most obvious name for it, adopting centuries of use and embracing decades of practice.
For a newborn programmer, every one of these names will be equally opaque: whether we name the thing Vector, Batch, or Run, they will have to look up its definition to learn what it means.
But what makes Vector so much better is that it immediately gets people with a little more experience into the right frame of mind, whether they are a recovering C++ programmer or were just force-fed a bit of linear algebra at college. It is really difficult to misunderstand the meaning of a "vector of 5 integers" -- the name already puts you in the correct ballpark.
For people with some maths background, the name Vector induces the automatic expectation of copyability, homogeneity, inline storage, and subscripting with integer indices. It strongly hints at the lack of insertion/removal operations, and the lack of concatenation. It fits the type miraculously well; far better than most names.
For C folks, it seems pretty straightforward to explain/understand that C arrays turn into Vector in Swift -- it's certainly easier to grok than the mess that is homogeneous tuples!
This is a good idea! It is a bit of a copout, but truncating the name still preserves the intuitive associations that I value so much about Vector. I don't hate it!