{"id":46771,"date":"2025-02-17T08:57:19","date_gmt":"2025-02-17T13:57:19","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=46771"},"modified":"2025-02-17T08:57:19","modified_gmt":"2025-02-17T13:57:19","slug":"swift-proposal-inlinearray","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/02\/17\/swift-proposal-inlinearray\/","title":{"rendered":"Swift Proposal: InlineArray"},"content":{"rendered":"

SE-0453<\/a>:<\/p>\n

This proposal introduces a new type to the standard library, InlineArray<\/code>, which is\na fixed-size array. This is analogous to the\nclassical C arrays T[N]<\/code><\/a>,\nC++’s std::array<T, N><\/code><\/a>,\nand Rust’s arrays [T; N]<\/code><\/a>.<\/p>

[…]<\/p>

It’s important to understand that Array<\/code> is a heap allocated growable data\nstructure which can be expensive and unnecessary in some situations. The next\nbest thing is to force a known quantity of elements onto the stack, probably by\nusing tuples.<\/p>

[…]<\/p>

We introduce a new top level type, InlineArray<\/code>, to the standard library which is a\nfixed-size contiguously inline allocated array. We’re defining “inline” as using\nthe most natural allocation pattern depending on the context of where this is\nused. It will be stack allocated most of the time, but as a class property\nmember it will be inline allocated on the heap with the rest of the properties.\nInlineArray<\/code> will never introduce an implicit heap allocation just for its storage\nalone.<\/p>

[…]<\/p>

InlineArray<\/code> will be a simple noncopyable struct capable of storing other potentially\nnoncopyable elements. It will be conditionally copyable only when its elements\nare.<\/p><\/blockquote>\n

Initialization is special-cased to avoid constructing a temporary array from the literal, and it does not<\/em> conform to Sequence<\/code> or Collection<\/code>.<\/p>\n

We do plan to propose new protocols that look like Sequence<\/code> and Collection<\/code>\nthat avoid implicit copying making them suitable for types like InlineArray<\/code> and\ncontainers of noncopyable elements.\nSE-0437 Noncopyable Standard Library Primitives<\/a>\ngoes into more depth about this rationale and mentions that creating new\nprotocols to support noncopyable containers with potentially noncopyable\nelements are all marked as future work.<\/p>\n

[…]<\/p>\n

With the introduction of InlineArray<\/code>, we have a unique opportunity to fix another\npain point within the language with regards to C interop. Currently, the Swift\ncompiler imports a C array of type T[24]<\/code> as a tuple of T<\/code> with 24 elements.<\/p><\/blockquote>\n

But they haven’t decided how to do that yet without breaking compatibility.<\/p>\n\n

Previously:<\/p>\n