# \[Second review\] SE-0453: Vector, a fixed size array **URL:** \ **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:** 11
**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, 11:36pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/208 "2024-12-14T23:36:27Z")
> [@Pippin](#): > > f 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. The existing functionality could belong to a variadic generic type with the form `Tuple`. (At one point during the discussion of variadic generics, constraints involving the length of variadics were also mooted. If such a feature is added, the type signature could be refined: `Tuple where length(repeat each count) == length(repeat each T)`.) It may or may not be practical to introduce a `Tuple` that evolves this functionality over multiple language versions. One thing I hadn’t considered is that this would constrain the tuple representation on _all_ platforms. Right now, only Darwin is committed to retaining the layout equivalence of tuples and C arrays due to ABI stability. ---
**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:41pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/209 "2024-12-14T23:41:45Z")
Would the following then be allowed? If not, I wouldn't like to say: Do you mean **t** uple or **T** uple for implementations. ```swift func foo(x: (Int, Int)) {} let bar = Tuple<2, Int>(1, 2) foo(x: bar) ``` ---
**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, 11:42pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/210 "2024-12-14T23:42:33Z")
Yes, that is indeed the end state I am putting forward. ---
**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:47pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/211 "2024-12-14T23:47:31Z")
That's not the worst thing in the world, I guess. However, I think what should have been proposed first would be `Tuple` while `Tuple<2, Int>` is just sugar for the homogenous type and we still have the same APIs as currently proposed, somehow. ---
**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, 11:49pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/212 "2024-12-14T23:49:03Z")
Yes, practicalities like that might make my proposal infeasible even if the LSG agrees with it in theory. At which point I’d fall back to my original suggestion of `InlineBuffer`. (To further justify my original suggestion: I like having the word `Inline` in the type to emphasize that an `InlineBuffer<200, Int128>` stored property is going to make your type fairly expensive to copy.) ---
**Author:** ![Jon\_Shier](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_shier/32/921_2.png) [@Jon\_Shier](https://forums.swift.org/u/Jon_Shier)\ **Post date:** [December 15, 2024, 2:02am UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/213 "2024-12-15T02:02:11Z")
Given the overly-verbose `HomogeneousTuple`, I'd like to submit `Huple` as an alternative. ```swift ┌──────────────┐ │ Huple │ └──────────────┘ │ ┌─────────┴─────────┐ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ Tuple │ │ InlineArray │ └──────────────┘ └──────────────┘ │ ▼ ┌───────────────┐ │ Array │ └───────────────┘ ``` ---
**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 15, 2024, 9:56am UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/214 "2024-12-15T09:56:23Z")
> [@allevato](#): > > 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 `Tuple` feels misleading and confusing given these differences. Allowing subscripting via `.0` etc doesn’t seem like it would be impossible for this type (at least in non-generic contexts where the `count` parameter is a static value)? The future direction of `ExpressibleByVectorLiteral` suggests it might be possible to use parameter packs - which have a link to tuples, so maybe using a tuple literal syntax for this type isn’t actually a bad idea? ---
**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\ **Post date:** [December 15, 2024, 3:58pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/215 "2024-12-15T15:58:53Z")
Tuples are homogeneous traditionally... (hmm, are they?) ~~If we want it badly we could always refer to the current swift tuples as "heterogeneous tuples" freeing up the word "tuple" to mean homogeneous by default.~~ ---
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [December 15, 2024, 6:30pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/216 "2024-12-15T18:30:31Z")
Yeah, you could imagine a world with an opaque byte type that would solve that specific example. It does generalize, though — I would say that most fixed-size array types in C are either implementation details of abstractions that you typically use opaquely (like a UUID) or act as buffers rather than being something you use as a whole. This is reinforced by the language in a way: C does not allow you to directly use fixed-size arrays as aggregate values because of array-to-pointer decay, so if you’re trying to do something UUID-ish, you _must_ wrap it in a struct, in a rare example of C accidentally encouraging fine-grained typing. ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [December 15, 2024, 7:31pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/217 "2024-12-15T19:31:28Z")
This, to me, is the clincher that this type should not be called `Vector`. This type, while useful, doesn't feel like one that would be exposed as a part of public API for a package; you would want to wrap it in a package-specific type to better convey what your intention would be. For example: - the names of a Mach-O segments and sections are `Vector<16, UInt8>` - A UUID is a `Vector<16, UInt8>` - vImage uses `Vector<16, UInt8>` for certain kinds of pixel conversion functions - an `FSCatalogInfo` exposes Finder info values via `Vector<16, UInt8>` - some networking frameworks expose IPv6 source and destination addresses as `Vector<16, UInt8>` For none of these would you want to _actually_ expose the values directly as a `Vector<16, UInt8>`; you would want to wrap them into `MachO.Segment.Name` structs or `UUID` or `PixelMap` or `FinderInfo` or `IPv6Address` structs that are _backed_ by a `Vector16, UInt8>`, so you could expose type-specific functionality for the domain. I have a hard time imagining a scenario where a `Vector` would be the _right_ thing to use as a bare public interface, as opposed to an implementation detail (that perhaps might be exposed as a property for use-case-specific situations, like as a `rawValue`). Because of that, and because of past history where we have regretted name-squatting things (`CountedSet`, `OrderedSet`, `CharacterSet`, etc immediately spring to mind), I think we _cannot_ use the name "Vector" to name this type. It's already been shown many times in this thread that there are many valid use cases for the name "Vector" that are domain-specific that this type _cannot_ encompass in its public API. `ConstantSizeArray`, `FixedCountStorage`, `NonResizingArray`, etc all seem to be far superior names in order to provide a _foundational_ type for package developers to rely on to build their own public interfaces. ---
**Author:** ![rauhul](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rauhul/32/35207_2.png) [@rauhul](https://forums.swift.org/u/rauhul)\ **Post date:** [December 15, 2024, 7:47pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/218 "2024-12-15T19:47:22Z")
> [@davedelong](#): > > `ConstantSizeArray`, `FixedCountStorage`, `NonResizingArray`, etc all seem to be far superior names in order to provide a _foundational_ type for package developers to rely on to build their own public interfaces. Why use an "xArray" name like two options above, if every use case you mention above is an "InlineBuffer". Also, echoing @lorentey, this type is _not_ an array. ---
**Author:** ![davedelong](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/davedelong/32/38708_2.png) [@davedelong](https://forums.swift.org/u/davedelong)\ **Post date:** [December 15, 2024, 7:54pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/219 "2024-12-15T19:54:11Z")
Like I've said before, I'm unswayed by the argument that the core proposition of an "Array" is the ability to make it a different size. A `const char[16]` is an array, even though it cannot be resized. Ever _other_ operation we use with arrays we would use with this one: maintaining order of elements, reading elements in O(1), replacing elements in O(1), etc. I don't know if that matches up with the "mathematical" definition of Array or whatever, but we're not computers who only speak math. We're building an API to be used by people, the vast majority of whom do not have advanced degrees in nor a deep understanding of mathematics. _Regardless_, "Buffer", "Storage", etc are acceptable suffixes to use for this as well IMO; anything except "Vector". ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [December 15, 2024, 8:20pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/220 "2024-12-15T20:20:03Z")
> [@davedelong](#): > > This, to me, is the clincher that this type should not be called `Vector`. This type, while useful, doesn't feel like one that would be exposed as a part of public API for a package The implied premise here, I would take it, is that _only_ types named in public APIs need to have "nice" names. I would disagree with that premise. As you show here, the proposed type has many implementation-level uses, and even if (arguendo) it _never_ appears as part of a public API, having an easily spelled and easily pronounced name would vastly improve the developer experience. IMO, half of the pain when working with `UnsafeMutableRawBufferPointer` APIs comes from constantly naming the type or its relatives—which, given how it's unsafe, can be stomached somewhat. _This_, however, is supposed to be a safe, performant alternative (for a subset of use cases), and I would _not_ want it to be pessimized the same way. > [@davedelong](#): > > It's already been shown many times in this thread that there are many valid use cases for the name "Vector" that are domain-specific that this type _cannot_ encompass in its public API. If there are _many_ domain-specific (and hence mutually incompatible) uses that can validly lay claim to the name "Vector," then I would say that for clarity _none_ of them should be using the unadorned name: they ought all to be `UIVector` or `MLVector` or some such—it's by no means absurd that someone would want to write a machine learning app with a user interface, which also happens to interop with C/C++/Rust code and does some SIMD computing. Indeed, I would then argue that having the standard library lay claim to bare "Vector" so that users are discouraged from declaring mutually incompatible `Vector`s would be a plus and not a minus. ---
**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\ **Post date:** [December 15, 2024, 9:33pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/221 "2024-12-15T21:33:38Z")
> [@xwu](#): > > Indeed, I would then argue that having the standard library lay claim to bare "Vector" so that users are discouraged from declaring mutually incompatible `Vector`s would be a plus and not a minus. The concern isn’t about different helper libraries trying to define their own currency type like String. The problem is that using the name Vector for a currency type clashes with one of the core types that a graphics or geometry library exists to define. And it just so happens that many programs which would use such a library would also like to be direct clients of `Swift.Vector`. > [@xwu](#): > > IMO, half of the pain when working with `UnsafeMutableRawBufferPointer` APIs comes from constantly naming the type or its relatives I do agree with this. Swift feels like it is actively questioning me every time I want to declare a pointer, which seems undesirable for a systems programming language. Whatever name is chosen, it should be succinct. ---
**Author:** ![brendon](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/brendon/32/44735_2.png) [@brendon](https://forums.swift.org/u/brendon)\ **Post date:** [December 16, 2024, 5:55am UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/222 "2024-12-16T05:55:52Z")
I have another name to consider: `Fix`. Why I like it: - It (hopefully) is easy to reconcile the name with a type having a static size and requiring all slots to have valid elements. - I find it appealing that the name makes some sense just from the “fasten” meaning of “fix”, as in “five ints fixed (fastened) together” for `Fix<5, Int>`. - It doesn’t have an existing meaning as a data structure in programming languages, as far as I know[1] - It doesn’t imply any functionality other than holding its contents [1]: There are functions named `fix` existing in some programming languages, but my brief search turned up multiple seemingly unrelated functions with the same name, suggesting no single accepted meaning even as a function. ---
**Author:** ![Lin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lin/32/44031_2.png) [@Lin](https://forums.swift.org/u/Lin)\ **Post date:** [December 16, 2024, 9:51am UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/223 "2024-12-16T09:51:17Z")
Just give another reason to support the awesome naming Vector: For Qt 6.0, the QVector is an alias to QList, so the meaning of Vector in the context of Qt will not conflict with any Qt datatype when Qt 6.0 gets adopted in the coming years. [https://www.qt.io/blog/qlist-changes-in-qt-6](https://www.qt.io/blog/qlist-changes-in-qt-6) ---
**Author:** ![HsilopNoitaton](https://avatars.discourse-cdn.com/v4/letter/h/dfb087/32.png) [@HsilopNoitaton](https://forums.swift.org/u/HsilopNoitaton)\ **Post date:** [December 16, 2024, 10:40am UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/224 "2024-12-16T10:40:43Z")
Just wanted to suggest possible names "Invarray" and "Procrustean". ---
**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\ **Post date:** [December 16, 2024, 12:29pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/225 "2024-12-16T12:29:35Z")
> [@John\_McCall](#): > > Hi, Dmitri. The overall approach was accepted after the first review; Freddy laid that out in the announcement. This review really is just focused on the name, although feedback on the other revisions mentioned in the announcement is also on-topic. Given this backdrop, are there any blockers in pursuing @dimi's ideas in some other way? I think I like it, or at least I'd like to explore that idea further. Could we envision some future where however we end up spelling it, for all practical intents and purposes the type-at-hand and tuples become more or less synonymous? Could we e.g. some time in the future say that `Vector<3, Int>` _is_ `(Int, Int, Int)`? Or make the distinction unimportant by adding stuff like `ExpressibleByTupleLiteral` to the type, toll-free bridging, adding new tuple literal shorthands such as `(3 * Int)`, making tuples extensible, and so on? ---
**Author:** ![hassila](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hassila/32/22647_2.png) [@hassila](https://forums.swift.org/u/hassila)\ **Post date:** [December 16, 2024, 12:58pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/226 "2024-12-16T12:58:00Z")
I think @John_McCall s point is that it has already been litigated and the ship sailed for that discussion with the first review - it is very hard to bring anything to a complete review if we reopen discussions and reset the overall approach at late(r) stages. (not commenting on the merits of that idea specifically) ---
**Author:** ![sveinhal](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/sveinhal/32/3992_2.png) [@sveinhal](https://forums.swift.org/u/sveinhal)\ **Post date:** [December 16, 2024, 1:03pm UTC](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412/227 "2024-12-16T13:03:39Z")
> [@hassila](#): > > I think @John_McCall s point is that it has already been litigated and the ship sailed for that discussion with the first review - it is very hard to bring anything to a complete review if we reopen discussions and reset the overall approach at late(r) stages. (not commenting on the merits of that idea specifically) I understood that, and that's why I'm asking about _other_ paths to a similar future, that does not involve altering the semantics of the type-at-hand. [Previous page](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412.md?page=10) [Next page](https://forums.swift.org/t/second-review-se-0453-vector-a-fixed-size-array/76412.md?page=12)