# \[Second review\] SE-0453: Vector, a fixed size array

**URL:** <https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412>\
**Category:** Proposal Reviews\
**Created:** [December 6, 2024, 4:37am UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412 "2024-12-06T04:37:37Z")\
**Posts on this page:** 20\
**Page:** 10

<div class="post-metadata">

**Author:** ![michelf](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michelf/32/1180_2.png) [@michelf](https://forums.swift.org/u/michelf)\
**Post date:** [December 14, 2024, 12:43pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/188 "2024-12-14T12:43:40Z")

</div>

> [@ibex](#):
>
> But that could conjure up `([...], ..., [...])` or `[(...), ..., (...)]`

`ArrayTuple` stands for array-like tuple, a tuple with some array behaviors, so I guess the literal should be parenthesis like a tuple: `(1, 2, 3)`. It probably should have a tuple-style shorthand syntax for the type such as `(3 * Int)` or `(3 Int)`.

Or we could have `TupleArray` for tuple-like array and then we'd get brackets: `[1, 2, 3]`.

I'm not saying these are good names, hence the "half-jokingly" qualifier I used. `HomogenousTuple` or `FixedSizeArray`, or even `InlineArray` (despite the conflict with the other projected type), would be less confusing I think.

---

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [December 14, 2024, 12:44pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/189 "2024-12-14T12:44:11Z")

</div>

A question not related to the name.

Will it be possible to initialize a Vector from a Swift tuple? Llibraries will have properties or function arguments as tuples for a long time.

```swift
// 3d party library code
let elements: (Uint16, Uint16, Uint16, Uint16, Uint16, Uint16, Uint16, Uint16) = ...

// our code
let vector: Vector<8, Uint16> = Vector(elements) // ?

```

Will it be possible? There is no information about such case in proposal.

It seems that C tuples can be transformed to Vector representation but Swift tuples doesn't.

---

<div class="post-metadata">

**Author:** ![FlorianPircher](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/florianpircher/32/39919_2.png) [@FlorianPircher](https://forums.swift.org/u/FlorianPircher)\
**Post date:** [December 14, 2024, 1:15pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/190 "2024-12-14T13:15:06Z")

</div>

Of the names proposed thus far, I like `Run` best. “A run of 16 ints” sounds natural and is unambiguous with existing Swift types. The name is short without being an abbreviation. It does not conflict with existing naming schemes and could serve as the base for a new set of names, if needed.

`Vector` is fine, but I dislike the conflation with geometric vectors and would like to see that name reserved for libraries dealing with such objects.

I think the name `Run` also _feels_ like inline storage to me, compared to `Slab` or `Buffer` or other names which are not explicitly `InlineSomething`.

---

<div class="post-metadata">

**Author:** ![HsilopNoitaton](https://avatars.discourse-cdn.com/v4/letter/h/dfb087/32.png) [@HsilopNoitaton](https://forums.swift.org/u/HsilopNoitaton)\
**Post date:** [December 14, 2024, 5:52pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/191 "2024-12-14T17:52:13Z")

</div>

How about "Indexee"? "Vector" would be fine if the language were being newly designed, but there must be a million programs that already have variables or functions called Vector, and even if these programs would still compile, they will become confusing for anyone to work on. I doubt many existing programs contain the word "Indexee".

---

<div class="post-metadata">

**Author:** ![Datagram](https://avatars.discourse-cdn.com/v4/letter/d/7cd45c/32.png) [@Datagram](https://forums.swift.org/u/Datagram)\
**Post date:** [December 14, 2024, 6:33pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/192 "2024-12-14T18:33:43Z")

</div>

About naming, I like both Vector and FixedArray.  
But also I understand the arguments expressed by John McCall.

> [@John\_McCall](#):
>
> I don't know what the name should be, but I feel strongly that it should not be `Vector`.

So what do you think about Cluster ?

```swift
Cluster a number of similar things that occur together

```

Just an idea

---

<div class="post-metadata">

**Author:** ![jaredgrubb](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jaredgrubb/32/22714_2.png) [@jaredgrubb](https://forums.swift.org/u/jaredgrubb)\
**Post date:** [December 14, 2024, 7:01pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/193 "2024-12-14T19:01:03Z")

</div>

I find it odd that, in order to avoid having to explain to C++ developers what `Vector` means, that we would then pick a random English word like `Slab` or `Bunch` -- that we would have to explain to _everyone_.

I rarely write `Array` or `Dictionary` because there's good syntactic sugar for them, and I hope the same will be true for this type.

Let's use plain words to describe exactly what it is. In my subjective ranked order from better to good:

- `FixedCountArray` - the `.count` property is what is fixed
- `FixedSizeArray` - this is more pleasant to my ear; the `Array` header-comments say "size" plenty so it's an ok synonym.
- `Vector` - This is fine; I'll get used to it.

---

<div class="post-metadata">

**Author:** ![pasi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pasi/32/1151_2.png) [@pasi](https://forums.swift.org/u/pasi)\
**Post date:** [December 14, 2024, 8:08pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/194 "2024-12-14T20:08:54Z")

</div>

For `String` we have `StaticString`. Wouldn't this then logically be `StaticArray`?

It's not a short name but anyone can guess what it is and how it behaves. I also feel like `Vector` will cause confusion.

Edit: Ah this was discussed already. Then my vote goes to `FixedSizeArray`.

---

<div class="post-metadata">

**Author:** ![Pippin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pippin/32/24826_2.png) [@Pippin](https://forums.swift.org/u/Pippin)\
**Post date:** [December 14, 2024, 8:21pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/195 "2024-12-14T20:21:58Z")

</div>

> [@pasi](#):
>
> For `String` we have `StaticString`

`Static_` defines an entirely different construct in the language as has been previously pointed out.

> [@Vector, a fixed-size array](https://forums.swift.org/t/vector-a-fixed-size-array/75264/23):
>
> Note: the pitched type is not static in the sense of StaticString or StaticBigInt.

---

<div class="post-metadata">

**Author:** ![crontab](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/crontab/32/7374_2.png) [@crontab](https://forums.swift.org/u/crontab)\
**Post date:** [December 14, 2024, 8:50pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/196 "2024-12-14T20:50:06Z")

</div>

> [@ibex](#):
>
> The name `Vector` will be embraced once the realisation occurs that a `Vector` is just a homogeneous `Tuple`. 🙂

`MonoTuple` then?

Been thinking about extending the existing native tuple type with new syntax for homogenous elements but I understand that the ship has sailed already, too late to propose this kind of changes after 189 comments under the second iteration... 🤷

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [December 14, 2024, 9:34pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/197 "2024-12-14T21:34:50Z")

</div>

A few people brought up tuples in the original discussion, [including myself](https://forums.swift.org/t/vector-a-fixed-size-array/75264/93):

> [@Vector, a fixed-size array](https://forums.swift.org/t/vector-a-fixed-size-array/75264/93):
>
> Endowing tuples with the ability to describe repeated elements would also give the language a way to describe the memory layout of any nominal type, including classes:

But @scanon enumerated several reasons why this approach was not taken:

> [@Vector, a fixed-size array](https://forums.swift.org/t/vector-a-fixed-size-array/75264/124):
>
> - Tuples are non-nominal types, so there's no way to conform them to, say Collection.
> - Tuple conformances can only express the special case of a tuple that conforms to a protocol because all of its elements do.
> - The ABI mangling for tuples is pretty awful when it comes to using them as a fixed-size container.
> - We have no good mechanism for talking about large homogeneous tuples in the language.
> - Plumbing initialization through tuples is kind of a mess.
> - Also there's a layout issue about tail padding.
> - and some other stuff

I still think the right approach is to resolve these issues instead of introducing a new language construct that models a precise subset of tuple functionality. Even with an ideal name that everyone could agree to, the existence of this new type will forever present the question of which to use in any given situation. The language is conceptually leaner with a single tuple type.

Is it at all feasible to name this type `Tuple` and commit to the eventual goal of making it the nominal generic supertype of all tuples?

---

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [December 14, 2024, 9:54pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/198 "2024-12-14T21:54:29Z")

</div>

> [@ksluder](#):
>
> resolve these issues instead of introducing a new language construct that models a precise subset of tuple functionality

The issue is not about tuples, it is about C interop – we have nothing better than tuple to represent a C array at this time.  
So Vector is a suitable construct for C arrays representation.

Swift tuples on their own will be used but for different purposes. I suppose no-one in Swift would create homogenous tuples with large count of elements – large tuples are a burden of importing C api's, because there was nothing better at the time when C interop was implemented.

I agree that it would be cool to have some collection-like operations for tuples, like access by index, iteration and count. Some languages have these features for tuples.  
The point is that in this concrete proposal improvements are about C arrays, not Swift tuples. As a bonus we get other Vector capabilities like inline storage and fixed capacity data structure useful on its own.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [December 14, 2024, 9:59pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/199 "2024-12-14T21:59:06Z")

</div>

> [@John\_McCall](#):
>
> I do not think a 2 or 3 word name of 10-20 characters (such as `FixedSizeArray`, although I understand the argument for avoiding `Array` as a suffix) poses a significant usability burden for this type. We often find ourselves using names of that size when we aren't specifically looking to introduce a new fundamental term of art into the lexicon, as we did with `Task` and `Span`. I do not see a compelling motivation to introduce a term of art for this type, other than that it is the proposal in front of us right now, which always makes a feature seem more important. We do not expect this to be the root name of a family of types, as `Array` and `Span` are. It is not expected to be an especially prominent type; it has a special role in language import, but so do `@convention(c)` function types. We are already talking about future directions like `InlineArray` as likely being more interesting for embedded programming in the long run, and that type does not appear to require a term of art. And we expect that this type will frequently conflict with the `Vector` types that library authors will need to offer on their own.

It is, however, conceptually a more foundational or primitive type, more so than even `Array`. I mean it in the following sense:

We learn how to create and use values of basic types like `Int` before we learn how to define even the simplest of data types. After learning about how to work with _one_ value at a time, a very reasonable next step is wanting to work with, say, _two_ or _three_ or _four_ such values.

Currently, the options for expressing this are: tuples, arrays, defining your own data types, and then more esoteric choices. _This_ data type is more primitive than all of these: it is _homogeneous_ where tuples are not (and also a _nominal_ type where tuples are not), _fixed_ in count where arrays are not, and a _standard_ type where your own types are not. Slotted into a textbook, it would be appropriate to present this topic before any of these existing topics—indeed, each of these (tuples, arrays, custom types) offers additional complexity to fulfill some particular need when the thing you're doing _outgrows_ this type in some particular way (for example: you have values of heterogeneous types, or you need dynamic resizing, or you _want_ copy-on-write, or you need to encapsulate business logic alongside your data).

For this reason, I feel very strongly that this type _isn't_ a good candidate for being named as an appendage of some other type, as most two- or three-word names tend to be. Instead, the name _should_ be legible to users who know nothing about the heap or stack, copy-on-write, dynamic sizing, or even what "storage" is: if you know what `Int` values are, this is merely `n` of them in order, and that is all there is to it as a threshold matter.

In that sense, it is _very_ different than `@convention(c)` or `InlineArray` or pretty much everything else.

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [December 14, 2024, 10:04pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/200 "2024-12-14T22:04:49Z")

</div>

> [@Dmitriy\_Ignatyev](#):
>
> The issue is not about tuples, it is about C interop – we have nothing better than tuple to represent a C array at this time.  
> So Vector is a suitable construct for C arrays representation.

Never did I suggest that C interop would avoid this new type. I’m saying the end state of the language is much cleaner if this type eventually becomes the nominal supertype of all tuples, including large homogenous ones imported from C.

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [December 14, 2024, 10:17pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/201 "2024-12-14T22:17:52Z")

</div>

> [@John\_McCall](#):
>
> In math, "vector" is pretty much exclusively used for a member of a linear space. All of our uses in CS are inspired by that, but they end up giving pretty different spins on the idea.

Now, I'm not a mathematician, but my impression on doing my reading is that the sense in which @lorentey is using "vector" in _this_ proposal is actually well precedented in math: for instance, the Wikipedia article on "ordered pair" calls out that it is _sometimes_ also called a "2-dimensional vector" even though it is technically an abuse of the term, which reads to me like if there is some "loosy goosy"-ness to it, that originates with mathematicians. So while other uses in computer science put a "spin" on it, we really wouldn't be doing any spinning here.

I definitely agree that a type spelled `Vector<2, Int>` is going to be tantalizing to someone who wants to use `SIMD2<Int>` in a way that's problematic when their memory alignment doesn't match. Addressing that issue by _naming_ choice would require us to "salt" the name of `Vector` sufficiently that no one likes it who should look for `SIMD2` first. That's sad.

Were feasibility not in question, I would much rather have us look into whether, for all `n` and `T` where `SIMDn<T>` is supported, `Vector<n, T>` could and should be made "magically" to have the same memory layout including alignment.

* * *

> [@John\_McCall](#):
>
> Those libraries could add the operations they want with extensions, but that would conflict awkwardly with the other use cases: we would not want an imported `char [MAX_PATH]` field to suddenly offer vector math when used from code that also imports a graphics library.

To my mind, that originates from a different "original sin" that has nothing to do with this type, which is only drawing it out.

Rather, we've always said that our fixed-width integer types model both the integers and the sequence of bits by which they are encoded. Here, this comes homes to roost because `Vector<MAX_PATH, CChar>` is being used for its "sequence-of-bits"-ness rather than its integer-ness. But we committed to this choice long ago; it would not be an issue if it'd been decided that bytes aren't to be represented by `UInt8` when it was decided (correctly) that `Bool` shouldn't be an integer type.

---

<div class="post-metadata">

**Author:** ![Dmitriy\_Ignatyev](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmitriy_ignatyev/32/11340_2.png) [@Dmitriy\_Ignatyev](https://forums.swift.org/u/Dmitriy_Ignatyev)\
**Post date:** [December 14, 2024, 10:20pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/202 "2024-12-14T22:20:09Z")

</div>

> [@ksluder](#):
>
> the end state of the language is much cleaner if this type eventually becomes the nominal supertype of all tuples, including large homogenous ones imported from C

Sure, as a final goal it is great.  
As a future direction some compiler magic can be added to make possible all Vector operations with homogenous tuples. In such a way it seems to be realistic.

---

<div class="post-metadata">

**Author:** ![benlings](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benlings/32/13011_2.png) [@benlings](https://forums.swift.org/u/benlings)\
**Post date:** [December 14, 2024, 10:50pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/203 "2024-12-14T22:50:55Z")

</div>

> [@michelf](#):
>
> `HomogenousTuple`

This seems to be the most common way this type has been described in English in this thread, so why not use this as the name? `HomogenousTuple` is pretty explicit about the layout (if you are familiar with tuples, modulo padding of the last element) and doesn’t have the mathematical or other-programming-language baggage of `Vector`.

(BTW, I don’t see the Vector/Array swap causing anything other than momentary confusion for C++ developers - it’s pretty clear from having an int value parameter on the type which is a fixed length!)

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [December 14, 2024, 11:02pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/204 "2024-12-14T23:02:39Z")

</div>

One problem with `HomogenousTuple` is that the canonical spelling should be `HomogeneousTuple`—"homogenous" is a biological term that has historically also been a misspelling for "homogeneous" but has occurred frequently enough that it's now considered by some to be an accepted alternative. But if that means the name would be hard to spell correctly, it's not a great choice for a name.

Other than that, the type being described here isn't really a tuple. Tuples provide compile-time-index access via `.0`, etc., whereas this type supports dynamic subscripting with `[...]`. Literals of tuple types are initialized using `(...)`, but this type is initialized using literals written with `[...]`. Calling it `<Adjective>Tuple` feels misleading and confusing given these differences.

---

<div class="post-metadata">

**Author:** ![crontab](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/crontab/32/7374_2.png) [@crontab](https://forums.swift.org/u/crontab)\
**Post date:** [December 14, 2024, 11:18pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/205 "2024-12-14T23:18:41Z")

</div>

> [@allevato](#):
>
> Tuples provide compile-time-index access via `.0`

In principle, Swift could support `.<expression>`, i.e. `t.i` or `t.(i + 1)`. I'm not a big fan of this myself but _in principle_ indexed access to a fixed-size array could be visually different from that of the variable-sized one.

> [@allevato](#):
>
> Literals of tuple types are initialized using `(...)`, but this type is initialized using literals written with `[...]`

Same, nothing terribly wrong in saying anything `[...]` is variable-sized whereas `(...`) is fixed sized.

> [@allevato](#):
>
> "homogenous" is a biological term that has historically also been a misspelling for "homogeneous"

Interesting (and useful) point but if we have somehow managed `Colour` vs `Color` or `.gray` vs. `.grey` (autocompletion help us all) I don't see a big problem with it. Besides, my suggestion was a more succinct `MonoTuple`.

---

<div class="post-metadata">

**Author:** ![Pippin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/pippin/32/24826_2.png) [@Pippin](https://forums.swift.org/u/Pippin)\
**Post date:** [December 14, 2024, 11:21pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/206 "2024-12-14T23:21:25Z")

</div>

For the `Tuple`/`_Tuple` name, imagine us explaining in the future:

This is a [homogenous] `Tuple` because it has a contiguous, inlined memory layout. These are collections of data that can be iterated over, randomly accessed, has a count, and are extendable.

However, _that_ differs from `()`-defined tuples, because those aren't necessarily homogenous and have entirely different syntax construction and operations like element-index-like dot syntax access, individual element labels, and allows same-structural usage.

The word "tuple" ambiguously means two different language constructs.

* * *

If this were some kind of super type of "tuples", I'm curious how that implementation would look alongside existing tuples. I believe we're way past being able to redefine tuples in this manner, imo.

---

<div class="post-metadata">

**Author:** ![ibex](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ibex/32/30439_2.png) [@ibex](https://forums.swift.org/u/ibex)\
**Post date:** [December 14, 2024, 11:26pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/207 "2024-12-14T23:26:37Z")

</div>

> [@ksluder](#):
>
> I still think the right approach is to resolve these issues instead of introducing a new language construct that models a precise subset of tuple functionality

> [@ksluder](#):
>
> Is it at all feasible to name this type `Tuple` and commit to the eventual goal of making it the nominal generic supertype of all tuples?

This is a brave argument, which I wholeheartedly support.

Let's, please, abandon all proposed names, including `Vector`, and embrace the true thing, which is `Tuple`.

```swift
// 3 by 3 identity vector
let u: Tuple <3,Tuple <3,Int>> = [1, 0, 0, 0, 1, 0, 0, 0, 1]

// Sugars
let u: [3 x [3 x Int]] = ...
let u: [3, [3, Int]] = ...
let u: [3 [3 Int]] = ...

```

[Previous page](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412.md?page=9)

[Next page](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412.md?page=11)