[Pitch] InlineArray type sugar

[Karl]

@ben-cohen

A heap-allocated fixed-size COW array is very niche, and of almost no utility compared to other array variants. [...]

Really the only benefit of a COW-but-fixed-size array is to facilitate compile-time micro optimizations based on its fixed size (e.g. potentially eliminate more bounds checks, autovectorize operations more efficiently). The times when these things are critical but you also want to make copies and are not mutating the array, just reading it (so not going to be hit by the uniqueness check cost), are likely vanishingly small.

Not necessarily.

The fixed-size nature of the type is a semantic attribute. It allows me to guarantee that the Array has a particular number of elements (including guaranteeing that it is not empty, which has a huge impact on its usability as it tells me I can safely force-unwrap queries such as the first/last/min/max/etc elements). It might be useful for optimisations, but not necessarily.

COW-protected heap storage is completely orthogonal to the fixed-size nature of the array. It gives you very cheap copies, which we found to be vital to making value semantics work with Swift's implied copyability model.

You can imagine developers wanting to use these fixed-size array literals for their semantic meaning and getting burned quite easily by the way it makes copies so much more expensive.

For example, in general property accesses may be a lot more expensive:

final class HoldsSomeData {
  var someData: [100 x Float]
}

// -- (there may be a module boundary here) --

func processData(_ x: HoldsSomeData) {
  let data = x.someData // Copies 100 floats.
}

Returning values from functions also generally needs to copy.

func processData(_ x: HoldsSomeData) -> [100 x Float] {
  x.someData // Copies 100 floats.
}

// Also: imagine the [100 x Float] was hidden behind a typealias...

Sometimes optimiser heroics can eliminate these copies, but that doesn't provide me much reassurance. Somebody could modularise their code and accidentally introduce an inlining barrier which makes these copies expensive again, and even if we could fix all of them, we'd still need to consider the performance of debug builds.

The cost of these copies was considered to be so significant that the proposal authors withdrew InlineArray's Sequence conformance and compatibility with for loops. But now they're... insignificant? Not worth drawing attention to? Something we expect people to 'just know'?

If you're enough of an expert, no doubt you can work around all of these performance traps. But I have found that most Swift developers have a difficult time understanding the copying cost of large value types. This isn't unique to inline arrays, it's a general problem in the language, but inline arrays make it so easy to define enormous value types that it becomes even harder to spot unless you have extremely detailed knowledge of the standard library. Especially when you consider how close these look to regular Array literals, and how Array has an entirely different storage model.