This is a big risk that the proposal does not address. It’s super easy to write [1024 x MyStruct]
, without realizing that copying that value will result in literally thousands of retain/release operations if you have multiple refcounted properties on it. The naming discussion of InlineArray
was so long in part because some people wanted to be very explicit about the fact that this type stores a potentially large number of values inline.
Adding this sugar now before any meaningful adoption has happened risks it becoming popular wherever a fixed-size array is desired without people specifically learning about its quirks.
I believe this feature should wait at least for a release or two so the community can get develop best practices for when and where it’s appropriate to use an inline array. Ideally we’d wait until the full set of non-copyable container types is in use in the wild (or at the very least pitched) as well. That way, everyone can gain experience around which container types are common and important enough to need a new dedicated syntax sugar.