During the review of SE-0483, a number of commenters have been asking and speculating about why the LSG allowed the proposal to come to review, given that some people had been quite negative about it in the pitch thread. That is not actually on-topic for the review thread, and it’s overwhelmed the actual review discussion a few times, so I’ve created this dedicated thread to sequester it.
245 messages about how much everyone hated x in the pitch thread, and we went to review with x?
No. -1 for x, and -1 for ignoring the "community review" aspect.
I'm aware that it's a hot-button bikeshed issue, but choosing the option with the weakest technical case and the least community support seems insane.
23 Likes
That's because none of the arguments stacked up.
Arguments that stacked up previously has changed the course of the history:
Vector --> InlineArray
1 Like
The arguments for InlineArray over Vector were very similar to those against x: potential confusion over current usage, other names being more expressive or accurate, and wanting "similar things to look similar". The arguments in favor are also very similar, mainly "if you look at it a particular way, it makes sense". For Vector that was "mathematically", for x it's "as you would look at wood".
12 Likes
6 posts were merged into an existing topic: SE-0483: InlineArray Literal Syntax
Clearly the core team has already made up its mind on this, but this is a false equivalence. All the examples you list are of ASCII operator symbols standing in for more complex math symbols. That is fundamentally different from using a letter for an operator.
6 Likes
Please don't make statements like this. The decision is not predetermined. The proposal advanced from pitch to review without changes because the proposal author was not convinced by the pitch discussion that any alternatives were better than the original proposal. Though we all have different individual preferences (as you can see in some of us participating in this review thread as individuals), the Language Steering Group was also not convinced and we knew the review discussion would debate alternatives no matter which alternative was brought forth for review.
We will make a final decision at the end of the review period. As always, the decision is not a vote; we will weigh the choices based on the merits and the tradeoffs. If you are leaving a comment in favor of or against one of the options, please try your best to articulate your reasons why.
Holly Borla
Review Manager
27 Likes
While the language steering group has reached no conclusion on this proposal, it may be worth mentioning that @GreatApe is technically correct that, well over a decade ago and in a thread that is too buried to locate even via search (and therefore based only on foggy memory), the core team as it was then constituted did pronounce, after a very long discussion just like this one, that (inspired by LLVM) they had made up their mind to adopt 4xInt as the sugar for this type in Swift when it should exist (and even though no such type existed at the time).
6 Likes
This is what a lot of us have suspected. I am hoping that the Core Team takes notes that this feature is overwhelmingly not being well received well by this forum for various reasons from "No sugar is needed" to "The syntax is inappropriate". Especially as it comes to the usage of x. A few of us have noted that something feels off about this (myself especially) and that this feels like an attempt to get in a feature before WWDC . Making this discussion somewhat disingenuous and exists only for the ceremony. Given your statement, I am inclined to believe that that is may really be the case. We're spinning our wheels to no avail.
None of these are malicious moral fallings, nobody is committing a crime, and we’re not trying to attack anyone, but this particular way of doing things is dishonest.
3 Likes
As Holly has made clear, in no way is any of that the case. I am not sure what part of my message would create this impression.
3 Likes
As a former member of the Core Team, I don't remember us saying anything like that. Even if we said we liked it (and I really don't know why we would've made any such statement officially!), I don't think we would have meant that as a hard commitment. As the LSG chair, I certainly wouldn't consider it to be binding on us now.
This is a common confusion, but please don't say Core Team when you mean the Language Steering Group. The Core Team is the governance team at the core of the Swift project, and they don't review language proposals. There was a time when they did, but that became unmanageable as the project grew, and we spun off the LSG as a separate team almost three years ago.
This is disingenuous. You are saying that the LSG is running a sham review with the prior intent of accepting the proposal regardless of what's said in the review. Since you've been told several times that that's not what's happening, you are also claiming that those people are lying.
You seem quite determined to ignore everything that the actual members of the LSG are telling you about how we see this. There is nothing predetermined here.
8 Likes
Let me try to explain the process here, because Holly described how this proposal went into review, but people seem to be over-interpreting that.
A proposal author writes a proposal and pitches it to the community. The community can provide feedback on the proposal to the author during the pitch. The author should engage with that feedback in the thread, and they should consider if and how to incorporate it into the proposal document. However, the author is not obliged to change their mind just because people in the community disagree with them. If the author sees a counter-proposal, seriously considers it, and decides they still prefer their original idea, they can and should stick with it.
When the LSG reviews a proposal document to decide whether to go into review, we are not checking to make sure that the proposal represents the majority view of the contributors to the pitch thread. The evolution process is not a vote, at this stage or any other. Instead, we are looking for three main things:
- We want the proposal to be viable as it stands. If the LSG thinks there's something so seriously wrong with a proposal that we can't imagine accepting it, we don't want to waste the community's time; but this is a weak standard and doesn't require consensus. If we think the proposal seems generally okay, we will bring it up for review specifically hoping to get the community's input on the questions we're not sure about.[1]
- We want the proposal document to do a good job explaining what's actually being proposed. We don't want the review to get bogged down in misunderstandings; people should be able to read the proposal and decide how they think about it.
- We want the proposal document to contain an effective argument for the proposal and explain why it was chosen over the alternatives. This includes a review of the pitch thread to make sure that any interesting ideas there are discussed in the document, either as alternatives or as future directions.
That third point is usually the hardest. Especially with long and contentious pitches, it's easy for us to overlook ideas that didn't get much discussion. I hope the community can be generous enough to recognize this as inadvertent rather than a slight. Holly has acknowledged a few missing points in this proposal that she's asked the author to cover better.
With that said, syntax often comes down to taste. We don't want to ask proposal authors to spend a lot of time inventing new ways to say "I think this looks better"; it doesn't help anything.
At the end of the review, the LSG will discuss the proposal and decide what we think the right thing to do is. That is not pre-judged by the fact that we put the proposal into review, and we will certainly consider alternatives that have been raised in the pitch and review threads.
If the review doesn't end up discussing these topics organically, we'll often ping the thread and specifically ask for thoughts about them. This isn't to say that we aren't considering input on other topics, of course, and I can point to any number of reviews where contributors have raised concerns that the LSG wasn't thinking about beforehand. ↩︎
50 Likes
To add a bit more, it is also not uncommon—after a first review—for the Group to accept parts of a proposal, or accept the proposal 'in principle' and return it for a targeted revision or re-review on some narrower question than the proposal as a whole. When this happens we make an effort to communicate clearly which portions of the proposal ought to be considered 'settled' and which bits are still under active consideration.
18 Likes
Thank you so much for your response. I will now be better to understand the difference between Core Team and Language Steering Group. That is something I was not paying close enough attention to.
I will also use first part of your response to me to negate my some of assumption, which I was integrating strongly into my thought process. I now understand that a version of this proposal was NOT so strongly adopted by the Language Steering Group at that time. Which helps to derail the rest of what I was saying and negates some of my fears that what I was perceiving in this discussion were true.
2 Likes
Right, it can’t be binding because any decision (such as there may have been) has been devoid of implementation for over a decade. It’s worth mentioning for the reason that Steve clarifies: we’ve had this discussion before and it’s good to remember how that went.
Predetermined might be too strong to describe the situation, but there is definitely a heavy bias in this topic.
Given the fact that the proposed syntax has been discussed internally for years, it is very unlikely that anyone outside the Core team comes up with a flash of inspiration that could actually change the final decision.
So basically the only thing the wider community can do is saying "I don't like this" in various ways — but as pointed out before, this is no vote, so it does not really matter what the community thinks.
On the other hand, I don't see much effort from the author to convince the opposers. That might be just because changing other peoples taste is a fruitless endeavor, but none the less, this feels like ignorance and naturally leads to frustration.
There is one benefit of the escalation, though:
If the team agrees surprisingly to chose an alternative, many people would be happy to get rid of the "x", even their favorite solution is discarded as well 
.
2 Likes
“Has been discussed internally for years” is a wild overstatement of the actual situation (“was discussed publicly for a couple weeks, approximately a decade ago.”)
9 Likes
Yeah, while there have been (a few) issues historically when things are squeezed through in a slightly dubious manner (resultbuilders comes to mind), I think that is quite unfair in this situation and not very helpful to the discussion.
That sounds like it is a bad thing to discuss something thoroughly, doesn't it? ;-)
I'm not speculating that there have been regular "fixed size array syntax"-meetings in the last ten years, but there was definitely enough time for opinions to settle — more so in the light of the precedent in llvm (imo that really should have been mentioned in the proposal itself) with its strong connections to Swift.
I was not blaming anyone for thinking in advance, but rather giving a plausible explanation why neither the pitch nor this thread had any visible (afaics) impact on the course of actions. For someone who believes the whole "[n x T]" idea was actually fresh, it is even more frustrating to see that none of their feedback is incorporated.
1 Like
I understand that people who dislike the proposed syntax are frustrated that it came to review. I did already explain at length how this works, though, and how it doesn’t mean we won’t have a real discussion of alternatives in the LSG. All this speculation that that discussion’s not really going to happen is honestly getting a little insulting, and it’s derailing other people’s attempts to actually discuss the proposal. I will be moving this discussion to a separate thread; in the meantime, please do not add to it here.
14 Likes