Swift accepts the of syntax for inline array types

Swift's shortest array spelling has favored its dynamically sized collection. Writing [Int] is easier than writing a nested generic type for a fixed-size buffer. That difference becomes more pronounced for matrices, where a type annotation repeats both size parameters and generic brackets. SE-0483 addresses the syntax while leaving the underlying storage type unchanged.

On August 5, the Language Steering Group accepted SE-0483. The accepted spelling is [5 of Int] for InlineArray<5, Int>. Hamish Knight and Ben Cohen's proposal makes this a compile-time equivalence. It does not introduce a second fixed-size collection or change the representation of an existing inline array.

I like Swift's ordinary collection model, particularly the way value semantics keep many mutations local. Fixed-size data needs a different representation when its size is part of the problem. Giving that representation a concise type spelling makes the choice easier to express without implying that every collection should have a static length.

Inline describes storage relative to its owner

SE-0453 defines InlineArray as a fixed-size, contiguous, inline collection. The elements live with the value instead of requiring a separate implicit heap allocation for the collection's storage. A local value can use stack storage, while an inline array held as a class property lives with that class's heap allocation.

That distinction prevents an inaccurate description of the feature as a guaranteed stack array. The relevant property is the absence of a separate allocation just for its storage. Where the enclosing value resides still matters. Syntax sugar does not override that allocation context.

The count is part of the type. An inline array with one count is consequently a different type from an inline array with another count, even when both contain the same element type. Its fixed-size model also requires initialized elements throughout. SE-0453 distinguishes this from a hypothetical fixed-capacity collection with an initialized prefix and unused capacity.

Those semantics suit a small vector whose coordinates have a fixed count. A growable list expresses a different requirement. Choosing between them concerns both the invariants the program needs and the storage behavior it wants, rather than the visual brevity of a declaration alone.

The shorthand preserves generic structure

The following examples illustrate the accepted proposal's spelling. This is an account of the accepted design, not a claim that the announcement changes the compiler installed on a developer's machine:

let coordinates: [3 of Double] = [1.0, 2.0, 3.0]
let repeated: [5 of Int] = .init(repeating: 99)
let matrix: [2 of [3 of Int]] = .init(
    repeating: .init(repeating: 0)
)

The matrix type retains the nesting of InlineArray<2, InlineArray<3, Int>>. Its outer element is itself a fixed-size inline array. The outer count therefore describes rows in this example, while the inner count describes the elements of each row. The proposal also permits inference placeholders for either parameter when the surrounding context supplies enough information.

A type expression can use the sugar wherever the underlying type could appear. SE-0483 gives initialization and MemoryLayout as examples. This follows from treating the spelling as an alias at compilation, rather than as a distinct runtime construction.

The grammar describes an expression before of, but the accepted design retains the restrictions of the underlying integer generic parameter. It currently permits integer literals or integer type parameters. The general-looking grammar therefore does not promise that arbitrary runtime arithmetic can determine the count of a type.

The delimiter changed during review

The second revision replaced an earlier x delimiter with of. The acceptance explains that of fits Swift's existing use of short prepositional keywords. It is also less likely than x to collide with a variable name used for the size parameter.

Other choices carry parsing or readability problems. Multiplication-like notation can make a count expression and a repeated value difficult to distinguish. The proposal discusses how this becomes more awkward if future syntax permits more expressive size expressions. An ordinary word separates the count from the element type without reusing an arithmetic operator.

Whitespace is required on both sides of of. A newline can follow the delimiter but cannot precede it, which the proposal connects to parser recovery and diagnostics. Those are grammar rules for the accepted spelling. They do not change how the inline array stores its elements.

Short syntax still requires knowledge of the type

Reviewers objected that the shorthand omits the word inline. A reader encountering [5 of Int] for the first time may not immediately infer the storage implications. The steering group acknowledged the concern but decided that programmers can learn the association, just as [Int] denotes Array without naming it.

The proposal's motivation goes further. Privileging only the dynamic array with concise syntax can encourage its use even when a known-size inline representation better matches the data. A small vector represented by a dynamic array can introduce an allocation and reference-counting behavior that a fixed inline representation avoids for its own storage.

I agree that unfamiliarity with syntax is a problem documentation can address. Understanding the allocation and copy behavior is still necessary for choosing the type. Adding the word inline to every annotation would not by itself teach the consequences of storing that value locally or inside a reference type.

Repeated-value syntax remains a separate question

SE-0483 discusses a possible future spelling for repeated values, but that is outside the accepted change. A notation such as [5 of 99] would need rules for initialization and potentially for dynamically sized arrays as well. It must not be presented as an accepted replacement for .init(repeating:).

The acceptance specifically recognizes that reusing similar syntax for inline and dynamic values could steer users toward inline storage unintentionally. The steering group leaves that concern for a separate value-syntax proposal. Type shorthand can proceed without deciding how every array value should be written.

The accepted sugar has no ABI representation of its own and relies on no runtime version. Existing source cannot already use this syntax, so the proposal does not reinterpret an existing expression. Its practical effect is to make a fixed count visible in a compact type annotation while preserving the semantics, layout, and generic rules of InlineArray.