# SE-0483: \`InlineArray\` Literal Syntax

**URL:** <https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643>\
**Category:** Proposal Reviews\
**Created:** [May 2, 2025, 7:11pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643 "2025-05-02T19:11:20Z")\
**Posts on this page:** 20\
**Page:** 17

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [May 16, 2025, 1:44pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/363 "2025-05-16T13:44:09Z")

</div>

> [@iressler](#):
>
> the name including `Inline` was important because of it's storage and associated hidden tradeoffs.
> 
> But adding this sugar will completely hide the name

I share that concern and wonder if, should the consensus of the community conclude that sugar for `InlineArray` is warranted, perhaps we should consider sugar that clearly communicates the important bit. Would a macro before an Array literal be appropriate?

_e.g._ an `@Inline(3) [Int]` that expands to `InlineArray<3, Int>` would still express the "inlineness" of the type, which I feel is important to communicate at the use site (and the community felt was important enough to change the name from `Vector` in the original pitch).

---

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [May 16, 2025, 2:29pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/364 "2025-05-16T14:29:11Z")

</div>

> [@perrinswanson](#):
>
> Examples like `[4 inline Int]` or `[3 inline [4 inline Int]]` read to me reasonably as shorthand for inline arrays.

Yes! This communicates all the important things in a clean and concise way. If sugar happens, this is the way I hope it does. It's very clear at the use site that what you are creating is not a regular `Array` and `inline` plainly tells you what to expect for this type's storage.

---

<div class="post-metadata">

**Author:** ![8675309](https://avatars.discourse-cdn.com/v4/letter/8/ea5d25/32.png) [@8675309](https://forums.swift.org/u/8675309)\
**Post date:** [May 16, 2025, 2:35pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/365 "2025-05-16T14:35:30Z")

</div>

> [@Orup70](#):
>
> ```swift
> var row = [32 x 17]
> 
> ```
> 
> Is it 32 integer values initialized to 17, or the other way around?

This makes it ambiguous as to the type a well, I read this as initializing a 2-dimensional matrix.

---

<div class="post-metadata">

**Author:** ![jaleel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jaleel/32/45076_2.png) [@jaleel](https://forums.swift.org/u/jaleel)\
**Post date:** [May 16, 2025, 3:16pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/366 "2025-05-16T15:16:07Z")

</div>

I'm overall +1 on adding sugar, and `x` looks fine (still not convinced though). But also feels like proposal is coming too early—people need to work/play a bit with `InlineArray` first.

---

<div class="post-metadata">

**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:** [May 16, 2025, 4:14pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/367 "2025-05-16T16:14:47Z")

</div>

As a general question, is it possible or likely that this syntax will become the literal for fixed size collections? Similar to `[]` for `Set`, would it be possible to simply make `InlineArray` the default inferred type for the literal, rather than the only type which can use it? Also, should we hedge against future fixed size dictionary-like collections and ensure the multiplier syntax works for both? e.g. `[5 x String: String]` or `[5 x [String: String]]` (neither are great there with the `x` operator).

---

<div class="post-metadata">

**Author:** ![Philippe\_Hausler](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/philippe_hausler/32/22569_2.png) [@Philippe\_Hausler](https://forums.swift.org/u/Philippe_Hausler)\
**Post date:** [May 16, 2025, 5:12pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/368 "2025-05-16T17:12:58Z")

</div>

This has been perhaps mentioned or eluded to before by others. I am not sure that a sugar for the `InlineArray` type is actually a good thing. As a matter of fact I think that it has potentials to be actively harmful to the intent that developers have when using it.

The common and expected use case for `InlineArray` is to store things inline inside a type, hence the discussion on the name of that type versus `Vector`. Particularly the name was chosen to express the "inline storage" nature of the type if I recall correctly (or at least that was the argument that was compelling for me...). The desire was to let developers know that perhaps passing these as arguments might not be ideal since there would be a copy that would be incurred.

How often do we find folks typing the signature of methods to have parameters of `Array<T>`? Instead we often type and find in code signatures of `[T]` - because the sugar is easy to understand. By having an easy to type signature of `[5 x Int]` or `[5 of Int]` etc, that will proliferate `InlineArray` as a type used as an argument; mainly because it looses the storage hint in the name. Which will by that additional usage, may obviate the performance gains that type is expected to grant. It will incur copy costs at the calls of those methods. Alternatively we should be encouraging folks to use `Span` or other such types as the parameter passing mechanism.

I find the concept of literal construction and repeating initializers very helpful and perhaps even required to use `InlineArray`. However, I don't believe that any cases of usages of this type would outweigh the costs from the existence of the shorthand.

---

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [May 16, 2025, 5:32pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/369 "2025-05-16T17:32:36Z")

</div>

While I'm not certain exactly what the 'right' level of callout for the inline-ness of `InlineArray` is, I _do_ think that even with sugar in place we still derive substantial benefit from having the name of the type be `InlineArray`—it's the term that will be used to refer to this type (just as everyone still calls `[Int]` an "array of ints" or "int array"), it's the name that will show up in documentation, etc.

The choice of `InlineArray` for the name was never a decision that the expensive-to-copy nature of this type must _necessarily_ be visible at the point-of-use, or in every interface. While sugar for this type might eschew the name a bit more, I don't think a decision to adopt a sugar which omits 'inline' contradicts the value of having `InlineArray` be the name (though I of course recognize the tension that reviewers are pointing to).

---

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [May 16, 2025, 6:24pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/370 "2025-05-16T18:24:17Z")

</div>

> [@austintatious](#):
>
> it needs to be useful elsewhere not just in the declaration site but also the call site

While I understand this sentiment, they don't have to be identical. We can have a declaration that conveys the vital implication that the type is `inline` (ideally by using `n inline T` in the definition) while having a different sugar at the call site (one that can be used for multiple contexts). I like the `n of T` as sugar for `n` comma-separated instances of `T`, and would like to see it available in many contexts such that all of these work:

```swift
let a: [Int] = [0, 0, 0] // Array<Int>
let a2: [Int] = [3 of 0] // equivalent to a
let b: [3 inline Int] = [0, 0, 0] // InlineArray<3, Int>
let b2: [3 inline Int] = [3 of 0] // equivalent to b
let c: (Int, Int, Int) = (0, 0, 0) // a three-arity tuple
let c2: (Int, Int, Int) = (3 of 0) // equivalent to c

```

I see the `n of T` to just be a shortcut to typing out `T, T, T, ...` out to `n` `T`s, and I think the type inference should be the same as if you had typed it out in full, so if all type annotations were removed from the above code I'd expect the type of `a`, `a2`, `b`, and `b2` to be `Array<Int>` and for the type of `c` and `c2` to be `(Int, Int, Int)`.

Despite the name of the topic, the literal is not what we are actually evaluating here, since that's relegated to the Future Directions section, so that can be saved for the inevitable future discussion. I just wanted to point out that the two do not have to be identical, and the priorities of characteristics for the two use cases are not the same. The type definition can be more explicit about the type's storage while the _value_ sugar for the literal can be shorter and more flexibly applied across multiple types.

---

<div class="post-metadata">

**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\
**Post date:** [May 17, 2025, 4:14pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/371 "2025-05-17T16:14:16Z")

</div>

> [@Jumhyn](#):
>
> The choice of `InlineArray` for the name was never a decision that the expensive-to-copy nature of this type must _necessarily_ be visible at the point-of-use, or in every interface

Right. The type is called `InlineArray` because the type needs a name and that name describes well what the type is. It is _not_ there as a "here be dragons" warning.

As I described [upthread](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/284), both `Array` and `InlineArray` have specific performance characteristics that are good or bad in different circumstances. This is not an "`Array` is fine and `InlineArray` is risky" situation, and as such it is a mistake to think that `Array` needs sugaring, but sugaring `InlineArray` is dangerous.

It is very common to see `Array` used for simple fixed-size values – for example let's say you're translating this code from the popular [Ray Tracing in One Weekend](https://raytracing.github.io/books/RayTracingInOneWeekend.html#thevec3class) tutorial:

```swift
class vec3 {
  public:
    double e[3];

    double x() const { return e[0]; }
    double y() const { return e[1]; }
    double z() const { return e[2]; }

    // etc
}

```

The way in which Swift privileges `[Double]` with sugar _strongly_ implies you should us that in this translation.\[1\] This would be a performance disaster. Every access to those coordinate accessors will need to check the bounds and, in the case of mutation, uniqueness of the pointer. Every `vec3` would start from the assumption of needing to allocate except when the compiler can do sufficient escape analysis to see it doesn't. Copying a `vec3` type would also incur reference counting that the compiler won't always be able to eliminate. This type is the hottest thing in the entire program, so will lead to an implementation way slower than the C++ equivalent. `InlineArray` has none of these problems.

There is no way to name our way out of understanding the performance characteristics of these types. I do not think it would help to name `Array` to `CopyOnWriteDynamicArray` nor do I think removing sugar from it would be appropriate just because it has these downsides. The same is true of `InlineArray`. And remember, every other language with an inline representation has sugar for this, and people are expected to understand what that means (in fact, most other languages comparable to Swift sugar the inline version, and do not sugar their dynamic version).

What is important is that we help shift the Swift culture around writing performant code away from "arrays are free and easy, don't worry about it" and towards "performance needs care, consider how your underlying code works and what the right tool is".

Of course, this only matters when you are trying to write code that maximizes performance. But that is a really important use case for Swift. The goal for Swift is a language that is as safe and enjoyable to write as many high-level non-performant languages, but also can achieve peak performance when that is your goal. And the idea is that when you are targeting that level of performance, you don't have to go into "ugly, no longer nice swift" mode to do it. For these reasons, we should be considering `InlineArray` a peer of `Array` (even if the need for it is less common – just not "niche").

* * *

1. of course, there are other options in this case, like `SIMD3<Double>`, but that isn't always an option for many use cases.

---

<div class="post-metadata">

**Author:** ![iressler](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/iressler/32/21526_2.png) [@iressler](https://forums.swift.org/u/iressler)\
**Post date:** [May 17, 2025, 7:12pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/372 "2025-05-17T19:12:16Z")

</div>

The recent posts by @Jumhyn & @ben-cohen have made it clear to me that the expectation for `InlineArray` is that it will be used for more than just "backing" properties, which makes sugar desirable. They've also reminded me that I'm so used to `Array` that I don't consciously think about it's costs like I am with `InlineArray`. Hopefully between a wider adoption than I expected and good documentation/tutorials about it's usage & tradeoffs my concerns about a sugar hiding the `Inline` property won't be the problem I expected.

So while I'm now in favor of sugar I'm still not convinced that `[5 x Int]` or similar is the correct syntax. My biggest sticking point is that by adopting this syntax we will be favoring `InlineArray` over any future fixed size `Array` types. I understand we can't block the present on a theoretical future, but since this will potentially block sugar for future fixed size `Array` types I think we either need to pick a sugar that can support other fixed size `Array` types, or address how they would (not?) get sugar.

I also have minor issues with `x` specifically, but nothing that hasn't been said many times already.

---

<div class="post-metadata">

**Author:** ![carlynorama](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/carlynorama/32/27072_2.png) [@carlynorama](https://forums.swift.org/u/carlynorama)\
**Post date:** [May 17, 2025, 8:16pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/373 "2025-05-17T20:16:23Z")

</div>

I 100% agree with Ben's two really good assessments ([A](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/284), [B](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/371)) of `Array` and `InlineArray` as peers but different. And I'm going to repeat my hope that he'll make an explainer blog post when `InlineArray` hits.

They don't make me feel better about having ambiguous sugar, though.

It's not that I don't want this type to never have sugar. I just don't want its entrance into the language delayed by finding the right sugar. Nor do I want it saddled with not quite right sugar just to not delay its release.

People have been really quick to generalize of their favorite sugar flavor "Oh look we could use it in so many places!"

Which sends up flags to me.

So, for example, what types do folks see the following declarations being inferred as? `Array`s or `InlineArray`s or...... ????

```swift
let inferred = [3 of 0]
//or say
let inferred2D = [5 x 3 x 0]

```

Would these raise compiler warnings about ambiguous type? In which case it isn't sugar for `InlineArray` at all, because you still have to put in the type. (which is why I put in a vote for rethinking `[...]`)

Perhaps what we are really discussing here is sugar for repeated values of a single type in general. That could be a really handy language feature. A lot of really good thinking has gone on in this thread about that. But perhaps its pitch should be disentangled from `InlineArray`, which won't be the only customer?

---

<div class="post-metadata">

**Author:** ![Nobody1707](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nobody1707/32/2169_2.png) [@Nobody1707](https://forums.swift.org/u/Nobody1707)\
**Post date:** [May 18, 2025, 2:17am UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/374 "2025-05-18T02:17:32Z")

</div>

The one is simple. `inferred` is unambiguously a zero initialized `InlineArray<3, Int>`.  
The second is a compile error, as the correct version would be written: `[5 x [3 x 0]]`, which is unambiguously a zero initialized `InlineArray<5, InlineArray<3, Int>>`.

Literals have a default type, and the default type for a future `[n x value]` or `[n of value]` literal would naturally be `InlineArray`.

---

<div class="post-metadata">

**Author:** ![toph42](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/toph42/32/7807_2.png) [@toph42](https://forums.swift.org/u/toph42)\
**Post date:** [May 18, 2025, 9:39pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/375 "2025-05-18T21:39:53Z")

</div>

> [@Nobody1707](#):
>
> The one is simple. `inferred` is unambiguously a zero initialized `InlineArray<3, Int>`.

That’s interesting because I think I would be surprised by this. I would expect the value sugared `[3 of 0]` to be equivalent to typing out the repeated zero, as `[0, 0, 0]` which is clearly and unambiguously an `Array<Int>`.

I’d like the type sugar to be clear what it’s defining and the value repetition sugar to be more succinct and also more widely applicable. I’d like a static `zero` method on `InlineArray` to give you an instance initialized to all zeros when `Element: Numeric` to make getting a new zero-filled `InlineArray` as easy as

```swift
let inferred = [3 inline Int].zero

```

(I like `n inline T` for the type sugar and `n of value` for the value sugar).

---

<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:** [May 19, 2025, 11:15am UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/376 "2025-05-19T11:15:58Z")

</div>

> [@iressler](#):
>
> The recent posts by @Jumhyn & @Ben_Cohen have made it clear to me that the expectation for `InlineArray` is that it will be used for more than just "backing" properties, which makes sugar desirable.

Some folks here are speaking to the question about whether the `InlineArray` type should _ever_ have syntactic sugar, while others have asked whether the type should _now_ have syntactic sugar (versus possibly later).

I think all can appreciate the very concrete benefits for a decision where, _if_ the `InlineArray` type needs syntactic sugar, its being delivered _now_ means that introduction of the type and introduction of the sugar aren't fragmented over multiple releases. @scanon also makes a good point above (or has it been moved into the other thread about the review process?) that a decade has passed without terribly much in the way of new ideas, suggesting that waiting _longer_ won't necessary get us _better_ results.

However, your post here illustrates one question which we don't have a good answer to _now_, and which we will have a answer to (probably soon) after the feature ships: we will _know_ (instead of having to _expect_) how the type will be used. It is noteworthy that there is a divergence of views currently on that point, and one perspective or other will inevitably be proven out in due course.

---

<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:** [May 19, 2025, 11:21am UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/377 "2025-05-19T11:21:13Z")

</div>

> [@CrystDragon](#):
>
> Also, start from your idea of musical notation, I'm wondering is it possible to reuse the existing keyword `repeat` from value/type packs
> 
> ```swift
> [5 repeat Int]
> // or
> [repeat 5 Int]
> // or
> (repeat 5 Int)
> 
> ```

It's worth remembering a weakness that has affected previous discussions of a `repeat n { ... }` syntax, which is probably inevitable every time we try to quantify repeats:

"Repeat once" is usually (correctly) taken to mean "do twice," and so by induction "repeat 5 times" is ambiguous as to whether the total count is 5 or 6. Most other words (or even `x`) are unambiguous in that context.

---

<div class="post-metadata">

**Author:** ![Andropov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andropov/32/35955_2.png) [@Andropov](https://forums.swift.org/u/Andropov)\
**Post date:** [May 19, 2025, 12:15pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/378 "2025-05-19T12:15:21Z")

</div>

> [@xwu](#):
>
> However, your post here illustrates one question which we don't have a good answer to _now_, and which we will have a answer to (probably soon) after the feature ships: we will _know_ (instead of having to _expect_) how the type will be used. It is noteworthy that there is a divergence of views currently on that point, and one perspective or other will inevitably be proven out in due course.

It's also true, however, that syntax sugar can massively influence how the type is used. So there's a risk of creating a self-fulfilling prophecy: since `InlineArray` _may_ not be a currency type, the sugar for it is put on hold, causing developers to avoid using `InlineArray` as a currency type.

I think in this respect it makes sense to look at how other languages are doing it. Are inline arrays used as currency types in other languages? Is there a reason —other than the sugar— why Swift developers would (overwhelmingly) prefer to use a wrapper type over `InlineArray`, for those same use cases?

In my particular bubble, the answer to that last question is _"no"_. There are far too many examples in which I have wished for an `InlineArray` while writing performant(ish) code in Swift yet I'd have had no interest in wrapping it into a custom type.

---

<div class="post-metadata">

**Author:** ![j-f1](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/j-f1/32/12287_2.png) [@j-f1](https://forums.swift.org/u/j-f1)\
**Post date:** [May 19, 2025, 1:16pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/379 "2025-05-19T13:16:31Z")

</div>

> [@xwu](#):
>
> It's worth remembering a weakness that has affected previous discussions of a `repeat n { ... }` syntax, which is probably inevitable every time we try to quantify repeats:

Swift also has the `repeat` keyword for variadic generics. The syntax for those is already relatively confusing (I don’t struggle with most Swift syntax, but I get at least one thing wrong each time I use variadic generics). Introducing another way one of the keywords could be used in a non-variadic context would only make this worse.

---

<div class="post-metadata">

**Author:** ![wes1](https://avatars.discourse-cdn.com/v4/letter/w/848f3c/32.png) [@wes1](https://forums.swift.org/u/wes1)\
**Post date:** [May 19, 2025, 8:57pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/380 "2025-05-19T20:57:22Z")

</div>

(tldr: `inline` + `repeat` is viable and arguably preferable, and does not suffer from ambiguity of the count)

> [@xwu](#):
>
> "Repeat once" is usually (correctly) taken to mean "do twice," and so by induction "repeat 5 times" is ambiguous as to whether the total count is 5 or 6. Most other words (or even `x`) are unambiguous in that context.

Let's be fair to the proposal for repeat. The phrase is "repeating {something} {some number of times}".

The current usage in Swift for initializers disambiguates the count explicitly: `init(repeating: {something}, count: {total number})`

The same is true for the proposal for repeat usage in `InlineArray`, where the requirement is to put the count type parameter first. (`repeat` is used here to distinguish the keyword form from the parameter name `repeating`.)

```swift
let ira: InlineArray<6, Int> = [6 repeat 7] // with count
let ira: InlineArray<6, Int> = [repeat 7] // count elided

```

So the problem is not the ambiguity of the count.

The problem is that `repeat` alone does not indicate that this is an inline array.

By default we should ask the literal to work on its own, both in meaning and in understanding:

```swift
let ira = [6 repeat 7] // what kind of array is this?

```

Here the sugar is not clear to the uninitiated (though it is probably clearer than `x` or `or`). Most uninitiated readers would read this as the stdlib `Array`.

That leads to the other problem with literal sugar: distinguishing members of a family of types with such repeating literals.

That led to being able say `inline` for the `InlineArray` literal sugar, notwithstanding the duplication, and use "repeat" only for the thing being repeated (not the count), in place of a series where the count is known. That also means "repeat" would work for repeating series of other series-consuming types.

So what are the rules for `inline` and `repeat`? This proposal is constrained to say the `InlineArray` count always precedes the type. It's fair to say that bidirectional type inference (B) should work for both count and element type

That gives us the following:

| Code | Rule |
| --- | --- |
| IT | `inline` is the distinguishing copula in the sugared type declaration |
| IL | `inline` in the literal indicates this is an InlineArray type |
| BC | count of the `InlineArray` can be inferred from the type declaration or the literal |
| BT | The element type of the `InlineArray` can be inferred from the type declaration or the literal |
| SC | the count of the `InlineArray` can be inferred from the count of a literal series |
| ST | the type of the `InlineArray` can be inferred from the type of a literal series |
| RL | `repeat x` in the literal indicates a series with a repeating literal where the count is otherwise given. |
| CP | The count may be a type parameter from the scope |
| TP | The type may be a type parameter from the scope |

The type declaration is:

| Type | Rules |
| --- | --- |
| InlineArray\<3, Int\> | |
| [3 inline Int] | IT |

Here are the key combinations of type declaration and literal (imagine `let ira {: type} = {literal}`):

| Type | Literal | Rules |
| --- | --- | --- |
| - | [inline 0, 3, 5] | IL, SC, ST |
| [inline] | [0, 3, 5] | IT, SC, ST |
| [inline] | [3 repeat 7] | IT, BC, RL, ST |
| [n inline] | [repeat 7] | IT, CP, RL, ST |
| - | [inline 0, 3, 5] | IL, SC, ST |
| - | [n inline repeat 7] | IL, RL, ST, CP |

If we also permit expressions in the repeat position where the index is available as a parameter:

| Code | Rule |
| --- | --- |
| RE | `repeat e` in the literal indicates a series with a repeating expression where the count is otherwise given. |

Then we also get repeat expressions:

| Type | Literal | Rules |
| --- | --- | --- |
| - | [n inline repeat { T($0) }] | IL, RE, ST, TP, CP, BC |
| [n inline] | [repeat { T($0) }] | IT, RE, ST, TP, CP, BC |

Some might argue that `repeat` or `inline` could be implied in some of these cases, but I believe that forecloses other types, and that the original stdlib `Array` should be the default.

Alongside `inline`, imagine using the same keyword-type pattern for the following related types:

- `buffer`: an inline array which can be resized within bounds on copy (where the count parameter is a `Range<Int>`)
- `slots`: inline storage of different types with the same shape accessible via Int index (where the type parameter can be a constrained tuple or parameter pack?)
- and so on...

I believe this pattern would work for all such types.

> [@xwu](#):
>
> Most other words (or even `x`) are unambiguous in that context.

I think both logic and discussion have shown "n x m" to be a defining example of ambiguity -- for the uninitiated. But `x` may indeed be preferable in a world where we can assume readers already understand the context and what `x` means. That could be fair: "Sugar" by definition is derivative, working as something easy to write for something otherwise hard to say. But the question is whether one must already know that association, and whether that particular brief expression scales across code.

Postfix '?', though considered sugar for Optional, is probably the conceptual form for readers, particularly given the corresponding infix `??` and postfix `!`. In that case, the sugar is primary or at least stands on its own. `[]` for `Array` is similar in this respect. Both are nicely orthogonal to the types they qualify and thus scale. But they might be rare if happy outliers.

I believe Swift should aspire to bidirectional inference between sugar and sugared, akin to what it does for types, and for the same reasons. Any proposal for a sugared form that does not clearly indicate the unsugared form (preferably without training) should have a higher bar for acceptance, minimally superiority in usage over alternatives. The loss of naive and local reasoning at scale is a burden.

I believe the combination of `inline` and `repeat` is an alternative, one not precluded by the question of count. The question (assuming it's still feasible) is whether its lack of brevity is made up for by the increase in clarity and teachability, the bi-directionality of understanding, and the ability to scale to related types.

---

<div class="post-metadata">

**Author:** ![Jumhyn](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jumhyn/32/3891_2.png) [@Jumhyn](https://forums.swift.org/u/Jumhyn)\
**Post date:** [May 19, 2025, 9:01pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/381 "2025-05-19T21:01:40Z")

</div>

I do, actually, think that `6 repeat 7` is ambiguous as to whether it means “6 repeated 7 times” or “6 repeats of 7”.

---

<div class="post-metadata">

**Author:** ![jpmhouston](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jpmhouston/32/4045_2.png) [@jpmhouston](https://forums.swift.org/u/jpmhouston)\
**Post date:** [May 19, 2025, 10:39pm UTC](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643/382 "2025-05-19T22:39:34Z")

</div>

To paraphrase a portion of that impressive post\[1\]:

> [@wes1](#):
>
> [n inline repeat 7] _follows rules_ IL, RL, ST, CP

With all due respect, **yikes!** While I appreciate the thought that's gone into this, I'm of the opinion that using multiple distinct keywords for the new sugared syntax, and 9 (maybe 10) rules for applying them, has gone way too far into the weeds for this language we call Swift. I'm not sure if initializers even have that many rules and intricacies.

In contrast, I'd suggest that there isn't much justification for using anything but matching syntax for sugared types and values literals, ie. the same keyword or symbol for both `[N blah Type]` and `[N blah value]` as suggested in the proposal, even if it means less expressive power.

In any case, thinking in advance about these possibilities isn't a bad idea, but this review is specifically for "sugared version of the `InlineArray` type" and despite being named "literal syntax" as it is, leaves sugar for value literals as a future direction. There's been so much in this thread already I think expanding the discussion into fine details of that future direction is a mistake right now.

+1 for the proposal from me, even though I'd prefer keyword `of` instead of `x`.

* * *

1. i'd quote the whole table but my markdown-fu is not that strong

[Previous page](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643.md?page=16)

[Next page](https://forums.swift.org/t/se-0483-inlinearray-literal-syntax/79643.md?page=18)