I don’t think that the opposition are afraid of having the syntax introduced, I think that the larger opposition are more confused and put off by the fact that the powers that be seem to be totally ignoring any critique of the syntax. It’s really curious. feel free to correct me if I misrepresenting my observations.
It’s almost as if the adoption of this feature has already been decided. And the syntax is set in stone.
I think a lot of us are feeling that (It could be just me). In a way this particular review felt more like ceremony than authentic.
How is it possible that in the pitch forum there was so much pushback, yet none of it was considered.
It seems that a majority of people don’t want x to be the keyword.
A secondary group doesn’t appears to believe that this feature is being introduced prematurely, and I would like to have evidence produced that demonstrates that this is needed.
I think that a lot of us understand that the review process is more of a validation effort of the core team and not a popularity contest.
But in this particular case, it does feel really backhanded (i know it’s not intentional) These groups tend to really value the power of auspicious discussions. I’m so thankful for the insight that I learned from these discussions. So I apologize if I sound harsh. But I’m really hoping that the court team reflects on this.
Moderator note: I think that's the last of it. Unfortunately, I kept finding posts or bits of posts that I should have moved earlier, so everything's a bit jumbled-up here now.
I really appreciate your efforts in keeping things organized, and I know others do as well! You've always been a very fair, engaged, and thoughtful moderator. Thank you for all your hard work.
Even without "regular fixed size array syntax meetings", n x T is a very natural spelling to anyone who spends significant time working with LLVM, because that's how LLVM spells homogeneous tuples in the form of SIMD vectors (LLVM Language Reference Manual — LLVM 21.0.0git documentation). That spelling is precedented, and honestly it works out pretty well, so it's not even a little bit surprising that contributors who deal a lot with the interface between Swift and SIL and the LLVM language would reach for that spelling a decade ago and reach for a variant of it again now.
By contrast, most of the alternatives proposed in both the pitch and review are either slightly worse in some way, or are newly invented whole-cloth, and should be held to a higher standard of evidence beyond "I like this more". I think that there are coherent arguments to be made in favor of some of the alternatives, and some people have been making them, but a lot of what I see is just "I don't like x," which should not be expected to move the needle or prevent a pitch from moving forward.
It's not a vote and Swift Evolution is not a democracy, but sometimes I think the LSG forgets that Swift only exists because of the app developers who make up the bulk of this community. Literally without the developers, who get no vote as has been stated many times, the LSG and Core team would not be Swift engineers.
The Language Steering Group runs reviews and solicits feedback on proposals precisely because this feedback influences our decisions, often dramatically. At the same time, we've always encouraged reviewers to state more than just their vote because often the reasoning behind an opinion is far more valuable for our decision making. A well reasoned argument demonstrating a fatal soundness hole in some proposed semantics, for instance, will carry immeasurably more weight than many votes in favor of the proposal as written.
While I'm sure they exist, I'm not aware of an open source community that runs their Evolution process equivalent by way of an open vote.1
1: I think PHP does run a formal voting period for their RFC process, but the voting population there is quite limited—just folks with commit access and designated community representatives
Personally, I don't expect this to be a democracy and I have no problem at all with some internal group making the decision. But since this is a review, I would expect the author and other proponents to at least try to convince the critics, with strong arguments and good examples for why x is superior to e.g. of.
Speaking for myself, I don't think it's reasonable to expect that authors will be able to convince every single reviewer of the proposal's merits. The choices made by a proposal will often come down to judgment calls about the proper tradeoffs between alternatives rather than, like, bright-line inconsistencies (especially since the policy change to require at least a prototype implementation before bringing proposals to review).
Folks who don't find the arguments put forth compelling should definitely make that known in the review thread (as well as elaborating on why they don't find the arguments convincing), but IMO it sets too high a bar to expect authors to try to individually convince all opponents, especially on points that ultimately amount to matters of taste. The audience for those arguments is the LSG, who will weigh the tradeoffs presented by the proposal author and reviewers, and make the final decision.
It would be relatively uncontroversial, I think, to say that the steering group will not require every single reviewer in the community to come to a consensus before or after review in order to approve a proposal.
My sense, though, is that one of the questions being asked here could be formulated as such: if a proposal comes to review with an idea which is then almost entirely disfavored by the community at large (for whatever reasons, weighty or arbitrary), would the steering group be willing nonetheless to approve such a feature on our perception of the merits and the substance of the feedback? Or put another way, can the community's intensity of feeling act as a veto over what the steering group considers an otherwise acceptable proposal?
As a group we haven't answered this outright, but in saying that we consider not votes but the substance of the arguments we do strongly hint that the answer is yes, we would consider approval in that scenario.
Speaking personally, I do think that is the right answer. To the point about substantive arguments, we want folks to think: "I [like/dislike] this part of the proposal, so I'd better muster up the best, soundest arguments in order to sway the decision," rather than, "I'd better summon the most or loudest reactions to sway the decision."
I caution that participation in a review thread is not an ideal proxy for the community at large. It's a highly selective group who reads them, let alone feels strongly enough about something to actually actively participate.
I believe it would be useful to get input from, or at least closer from, the actual community at large. That's probably very hard to do, so perhaps the opinion of educators and others working with developers of varying levels of experience could be sought instead.
I have always taken the situation to be that the LSG makes decisions about the language based on their own views about what’s best for the language’s stakeholders—of which posters on the community discussion board are a small subset—and that the pitch and review process is meant to generate useful considerations for the LSG to take as inputs when making those decisions. At the end of the day, while everyone likes to feel listened to, I don’t think there’s a stated obligation by the LSG or anyone to answer all criticisms or to share or even extensively debate the views of the majority of posters here.
There are inevitably questions of priorities and even taste that are going to be settled by the people charged with making decisions. That is okay. Whether the syntax for this moderately niche feature is x, by, of, inline, or just the standard type initializer, the Earth will go on spinning.
Even if it was a popularity contest, it's hard to gauge how the community feels about a proposal just by looking at the comments in the review thread. People that read through a proposal and are convinced by its arguments and generally satisfied with it are far less likely to comment on the review thread than people that read through the proposal and dislike it. Particularly if they viscerally dislike some aspect of it, as it often happens with matters of taste.
That's not quite true. They do listen when the arguments stack up.
Recent history: Vector --> InlineArray.
I strongly believe that designing a language or a system is one of those adventures where having too many cooks, especially inexperienced ones, can be fatal.
Personally, I have a hard rule about posting messages evaluating technical decisions (in this case, syntax): I disallow myself from expressing unsubstantiated personal opinion. If I have an opinion that is not based on objective fact, then it is either a wrong opinion that has to change, or the objective fact is there, so it must be brought to light. That is exactly the point of all my messages. My messages in the InlineArray type naming thread were entirely composed of case studies and objective arguments, and so are the ones in the syntax sugar thread. If at any point I slip up and express a baseless opinion, I'll take down my post and apologize immediately upon noticing.
Having said that, I do wish that rational counter-arguments would get more attention from the author and LSG. I understand that it may be difficult to sift through all "pure opinion" posts, which is why I 'm not complaining about it.
I’ve noticed comments in a lot of review acceptances that would suggest the communities feeling about a review has at least a strong value, if not a veto.
Comments such as “the feedback was mostly positive” are common in review responses, and these would seem to indicate that the sentiment in the thread had intrinsic value.
If community sentiment is not relevant, but only reasoned argument, it might be better phrased as “there were no significant issues raised” and left at that.
Some phrase to the effect of "the feedback was mostly positive" is very commonly written because, well, feedback communicating positive sentiment is very common. I like to think that in our decision notes we report out pretty accurately what we discuss, which in the case of a review thread in which the feedback is mostly positive would be a summary along the lines of that exact sentence: "the feedback was mostly positive."
While of course everyone likes receiving nice comments, I think steering group members have made clear enough throughout the years the intrinsic relevance of a slew of something like "+1" to our discussions. Which, again, to be concrete, would be summarized when we meet in a passing sentence more or less like, "the feedback was mostly positive."
I think I speak for more than just myself in saying, in our role as steering group members, we are not constantly writing sentences loaded with hidden messages and suggestions. I promise you that there is not more or less to read into our frequent use of the sentence that "the feedback was mostly positive" than the bare fact that, frequently, "the feedback was mostly positive."
Right, this representativeness issue is one big part of why treating things as a vote is not really workable.
I would add that even something like "-1, this seems overly complicated", or "+1, I've had this issue" is much more helpful than merely "-1" or "+1". Ultimately many of the decisions the LSG make come down to opinionated judgement calls, and so I think insisting that all decisions be made on a purely deductive basis with cold hard logic to support each choice is an opposite sort of unworkable extreme from "all decisions should be based on a community vote."
Which I suppose is to say that I think this:
is a bit overly restrictive as a general rule for permissible or useful participation. Everyone can of course have a different bar for what they feel is a valuable contribution worth spending their own time on, but I will say that I do still find value in reading the subjective, squishy feelings of others. Indeed, one of the prompt questions in our reviews is whether the proposal fits with the "feel" of Swift—we don't have a formal language spec at all, much less one for what "Swifty" actually means.
While 'soft' arguments like that may not tip the scales against a strong, well-reasoned technical argument on some point, there are certainly positions I've held myself (e.g., "this is a very clear and self-evident spelling for the proposed feature") which have been shifted by people chiming in to provide feedback that's a bit more 'vibes-based' (e.g. "I thought this meant something completely different until I read the entire proposal carefully"). And in those cases, I do think there is some marginal benefit to my own opinion-forming process in knowing at a coarse level whether that sentiment is rare, common, or overwhelming. But beyond that coarse level I think trying to pick things apart is not really helpful for making an informed decision.
