To me mutation operations do not make an array. It is all the other things pointed out by @beccadex:
Indexing by a continuous range of integers
Arbitrary positioning of elements (unlike e.g. a set that controls the position of each element)
Iteration in position order
O(1) access and replacement of elements in the common case
Homogeneous element type, to the extent the language's type system supports the concept
All of these operations are things I see on this type and to me it makes sense that it is then some type of Array and following the naming of other types like OrderedSet it should be something like FixedSizeArray.
Steve's said most of what I wanted to say as Review Manager, so will just add that (1) and (2) are important inputs to (3), if that's what it comes down to. The Language Steering Group has solicited this naming discussion (and indeed, dedicated more or less an entirely separate review thread to it) because we recognize that there are reasonable, well-motivated, differing opinions about what a good name for this type is (as well as what constitutes a 'good name' more broadly), and we do not want to be making a decision in a vacuum without those arguments having had a chance to be surfaced.
I prefer FixedSizeArray over FixedArray. The latter feels strongly to me like we are implying regular Array is somehow broken. I have seen developers add their own FixedX types in the past where they need to adjust some aspect of X's interface that was very inconvenient for their usecase ("broken" in their eyes), or even literally to expose the same API but fix bugs.
A description is not a name, but I think a good name should be descriptive.
I think that people who argue that arrays can be fixed in size (e.g. in other languages) so we should call this a "FixedArray" or "FixedSizeArray" are missing @lorentey's fundamental point: Swift already has an Array type, and there are plans to introduce a family of related types (ContiguousArray, InlineArray etc.) which share the same basic API. Using the word "Array" in naming a type that doesn't belong to this family would create unnecessary confusion.
Maybe we should spend a little time exploring the difference between an âarrayâ and a âbuffer.â I would argue that âbufferâ is a lower-level concept than âarray,â at least how Swift uses these terms. A Swift Array is built from one or more Buffers, which mediate all of Arrayâs memory operations. Likewise, clients of Array must ask for a sequence of Buffers to get at the memory where the Arrayâs elements are stored. I conclude that Swiftâs long-standing convention is that if you care about where something lives in memory, you work with Buffers.
Since the fundamental difference between this data type and Swiftâs existing Buffer and Array data types is that the memory for its elements is stored inline with the value itself, I believe this type constitutes a Buffer, not an Array. When it comes to what kind of buffer, I would not call it Fixed, because that term is too closely associated with having a fixed address, which values of this type will not have even if they are move-only. Again, since the distinguishing characteristic of this type is that its elements are stored inline, I would call this type InlineBuffer.
Another argument against calling this type an Array: soon, Span will replace Buffer in some circumstances by separating the concept of âa view of memoryâ from ownership of that memory. If the LSG calls this type FixedArray, I wonder if there will also be a strong desire to rename Span as some other flavor of array, perhaps TransientArray or UnownedArray. I would find that unfortunate and confusing.
If C++ hadn't "done it wrong" so to speakâif std::array were dynamically sized and std::vector were fixed sizeâwould we be having this conversation? Would there be serious objection that Vector's elements aren't of a vector space?
(For that matter, has any C++ user actually struggled with using std::vector because its elements are not of a vector space?)
And on the flip side, if Objective-C (and then Swift) had "done it wrong"âif Vector were the name of dynamically sized arraysâwould we be struggling with calling this an Array?
My hunch is that, as @Ben_Cohen focuses in on, it boils down to C/C++ and Objective-C disagreeing. It's not really about whether the standard library is going to be squatting on a name that others want, it's more that our bridged languages have squatted on names that we'd otherwise use here.
If we define a type family in terms of its API, this doesn't seem to be closely related to Array, in contrast to the family of Array types that Lorentey is working on.
I like the idea of including Inline in the name. It is consistent with a future InlineArray which would actually support both inline elements and falling back to an allocation.
Saying that, are we willing to add an Inline version of a type, if there's no plan to add a non-inline version? I don't think that's a problem, but curious what others think? I think what I just asked doesn't actually apply to Buffer, but would we ever call a type InlineSlab if we didn't plan to add a regular Slab, for example.
I'm trying to evaluate InlineBuffer. Maybe it could be just Buffer?
Buffer is not my preferred word for the type when taken in isolation (something based on array feels more natural to me), but calling it a buffer seems like it'd play well with our unsafe-buffer-pointer-type family.
So it could look like this:
Buffer<4, CChar> is a compile-time sized array, stored inline.
UnsafeBufferPointer<CChar> is a pointer for a runtime sized array (not meaning resizable, just that the size is only known at runtime).
UnsafePointer<Buffer<4, CChar>> is a pointer for a compile-time sized array
When working with C arrays in C APIs, you always end up using pointers. It would be convenient if the pointer API and the "fixed-size array" API were using same words for the same thing. And since we're already using the word "buffer" on the pointer side, that's the word we should use on the other side.
My objection to narrowly defining the word array in Swift as requiring resizing is that then weâll need to come up with some other word to describe the umbrella of resizing and non-resizing ordered collections. And that would frankly be a more difficult naming exercise than this has been.
Letâs leave array as an ordered collection at the top of the taxonomy chart. Below it there are two families - resizing and non-resizing (and likely others).
I like the name InlineBuffer, but I'm also compelled by @lorentey's argument that an important, defining characteristic of Buffer types in Swift is that they admit an undefined state of initialization, which the proposed Vector does not. We may in the future have a Buffer type which is stored inline, has a fixed size, and can be in an uninitialized state that should be named InlineBuffer.
Not at all the single fundamental property, but definitely one of the core properties. I wouldn't consider something that can't be dynamically indexed a Swift array either, for example.
Again, I haven't seen anyone calling simd types arrays in Swift. People already call those vectors (and will keep doing so). Other than the memory alignment requirements of SIMD types, SIMD64<Float> and Vector<64, Float> seem to be more closely related than [Float] and Vector<64, Float> (as far as the methods each type exposes).
I agree that newcomers don't start by distilling the fundamental concept of what a data structure is, I wasn't suggesting that.
Actually, it's precisely because they don't that I find the choice FixedArray concerning. Any statements around "arrays" would have a wild list of exceptions, and the language should make an effort to make this exceptions evident simply by using different names for types once they differ in more than a few core properties. A FixedArray name, for example, hides the fact that unlike arrays, storage is inline, so initializing a big FixedArray may unexpectedly crash by not fitting in the stack, leaving users confused as to why Array works but FixedArray crashes. It's just like an array but with a fixed size, right? Why would one crash but not the other?
As to whether or not the fixed size is one of those core properties worth sparing a new name: in my experience, most people new to programming get a 'vibe' or mental model of the concept based on the (little) API surface they have used so far. For arrays I believe this minimal API boils down to this:
Indexing with [index].
Adding and removing elements with append()/remove(at:) or similar.
Iterating using for element in array loops.
This are probably the 3 things all Swift newbies can name about arrays off the top of their heads. Adding/removing elements is already one of just 3 "things" they can do with arrays. Without that, for them an array is... something that can be indexed and iterated over? But certainly not anything that can be indexed or iterated over...
Thank you everyone for your participation in this second review of SE-0453âthe review period has now concluded. The Language Steering Group will consider all of the arguments raised in this thread and share an update on our decision as soon as it is available.