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, 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 tutorial:
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").
of course, there are other options in this case, like
SIMD3<Double>, but that isn't always an option for many use cases. âŠī¸