SE-0483: `InlineArray` Literal Syntax

Evolution Proposal Reviews
383

From the pitch thread:

I think it would make the value sugar (future direction) more self-explanatory.

let a = [3x 4] // Obviously `[4, 4, 4]` and not `[3, 3, 3, 3]`

However, I'm not sure about using _x or (_)x for an inferred count.

I also think tuples need a similar syntax. For example, in Foundation.UUID public APIs:

typealias uuid_t = (16x UInt8)
var uuid: uuid_t = (16x 0)
3 Likes
384

  • What is your evaluation of the proposal?

    I can understand that declarations like InlineArray<3, Int> are verbose, but it seems that the verbosity could be cut down significantly by introducing a typealias, as others in the thread have mentioned.

    I think it would make sense to first have InlineArray actually ship in a general release and see if using a typealias addresses the problem. And then if not, revisit this proposal.

    I also see a number of comments in the review thread trying to see if the proposed syntax will translate well into the value sugar syntax. I think the two are so closely related that they should be proposed and considered together.

  • Is the problem being addressed significant enough to warrant a change to Swift?

    Since InlineArray itself hasn't been released as part of a general Swift release, it seems like it is impossible to tell how significant the problem is across the Swift community.

  • Does this proposal fit well with the feel and direction of Swift?

    It's always seemed to me that Swift is generally slow to add sugar and only after the pain point of not having the sugar has been demonstrated over time.

    This proposal seems like the complete opposite with a rush to sugar something that hasn't even been in a general release of the language.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

    I read the proposal a few times, read through a lot of the review thread, and did my own little mockup of different variations of alternative sugar.

11 Likes
385

That's part of why the inline+repeat proposal expressly prohibits that locution [edit: when standalone]. For literals (as a future direction), it would be [6 inline repeat 7] (which itself has drawbacks mentioned up-thread).

386

Have we considered this to highlight "inline-ness"?

[|3 x Int|]
[|3 x 0|]
[|x Int|]

potentially with "of" instead of "x".

1 Like
387

Yes (or at least something very like it).

388

If we had to add a syntax sugar, I'd vote for “[100, Int]” because it's consistent with the structure of InlineArray<100, Int>. As for x/X or *, all I can say is that it looks like a matrix rather than an array

And when nested, it's more readable if we separate them with “,”:
[100, [3, [2, Int]]]

5 Likes
389

Let me try to solve this in a different way that is applicable for all types: generic argument labels.

InlineArray<size: 3, of: Int>
3 Likes
390

Thank you all for your candid feedback. The proposal author has revised the proposal to change the separator from x to of, and to incorporate more discussion of the concerns raised in this review discussion.

I’ve kicked off a revision review of these changes. Please continue the review discussion in this thread:

Holly Borla
Review Manager

13 Likes