The second review of SE-0483: InlineArray Type Sugar has concluded. The Language Steering Group believes that inline array type sugar is an important ergonomic win for high-performance Swift code, and has decided to accept the proposal.
The second revision of the proposal changed the delimiter from x to of, and much of the review discussion focused on whether of is the best choice. The Language Steering Group agrees that of is a better delimiter than x because it fits in naturally with Swift’s other prepositional keywords (e.g. in, as), and it is unlikely that of will conflict with variable names that may be used as the array size. Many reviewers surfaced the concern that the type sugar syntax does not include the word “inline”, making the performance implications less obvious when you encounter the syntax for the first time. In addition to the arguments presented in the proposal, the Language Steering Group believes that the syntax choice should not prioritize programmers encountering syntax for the first time, and programmers will learn to associated the type sugar with an inline array, just as programmers associate the [Int] syntax with "Array".
Reviewers also surfaced concerns about the future direction of extending the of sugar to array values; using the same sugar for both values of inline arrays and dynamically-sized arrays might encourage programmers who would otherwise stick to dynamically-sized arrays to inadvertently reach for inline arrays. The LSG sees this concern as a reason to consider a different syntax for value sugar if we pursue that direction in the future, and not as a reason to change the design decisions in this proposal. Any future proposal to introduce sugar for initializing arrays of repeating values will have to address with these fundamental questions, no matter what type sugar Swift adopts for InlineArray.
As always, thank you to everyone who participated in the pitch and proposal review. Your contributions help make Swift a better language.
@ksluder - It's a really odd grammar. I was genuinely interested to know why the only options that were considered in the Alternatives Considered section of the proposal were limited to a few slight variations on the same idea. Fairly obvious options were apparently never considered.
For example, the pitch was originally posted on April 7th, and the most recent post there was May 7th. Things move too fast (considering how hard it is to change anything once it ships), and we end up with half-baked stuff like [5 of Int].
I don't think you can reasonably complain that the process moved too quickly for you to participate. The total review process took about four months. There was a month-long pitch followed by two separate extended reviews. You were even active on the forums during that time.
Kyle is right. I'm sorry that you don't like the syntax that was chosen, but you're not adding anything to the discussion that wasn't brought up already.
I'm not particularly bothered that I didn't get to participate personally (I don't participate in the process much anyway, and don't expect to have much influence). Besides, I'm confident that better syntax would've been suggested by somebody, given a bit more time. That's the point I was making.
It's not even the rate of progress generally. It's really adding new syntax without enough consideration that annoyed me a little.
If we add new features or semantics that suck a bit, there's scope for fixing things later, even though the cost is high. Once syntax like [5 of Int] ships, it's not feasible to change it (we can't even change it now).
I should've probably started a new thread, and just referenced this announcement as an example, but I originally only intended to comment on the issue briefly, and leave it there.
Between the pitch and two reviews, there were 676 replies. What you're asking makes it clear you didn't and still haven't read them. Which is fine—you don't have to (the language steering group does)—but then you don't get to conclude that there's not been "enough consideration."
I don't mean to be pedantic, but it's not my conclusion. It's what the proposal says. It has a section titled Alternatives Considered, which doesn't contain any alternatives, beyond minor variations on [5 of Int].
I didn't read all of the history behind the proposal, because I assumed the proposal would be reasonably complete in its summary of alternatives considered. I realize now that the conversation was much more involved than what was documented in the proposal. Sorry that I got the wrong impression.
All the same, four months is a relatively short time for a standards process.
The "Alternatives Considered" section is not a summary of review comments; if updated after review it's usually to describe an earlier version of the proposal. The proposal is not just reasonably complete: it is entirely complete by directly linking to every step of the process in the header. If what's there is already too complete and too long to read, then it can't also be too incomplete a document and too short a process, can it?