<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">While I preferred a different solution, here, I think that the current “do not design by committee” process is a good one, and the accepted solution is definite improvement. A consistent vision is critical to a project as complex as this. It is certainly in Apple’s DNA, and has served it, and the world, well.</div><div class=""><br class=""></div><div class="">This proposal is one step in achieving overarching goal: "to preserve higher-level consistency throughout the language in how components of expressions and statements are separated” </div><div class=""><br class=""></div><div class="">Well, if you want consistency, why not work through all the cases before freezing on one point solution? Perhaps the process should be expanded to formalize the overarching goal and put proposals like this under it. The process could be something like:</div><div class=""><br class=""></div><div class="">1) Propose goal, and list of point solutions, e.g. “...condition clauses..."</div><div class="">2) Review, refine and accept the goal</div><div class="">3) Work through tentative point solutions</div><div class="">4) Review the entire set of solutions.</div><div class="">5) Accept the solution set.</div><div class=""><br class=""></div><div class="">There is distinct possibility that working though other tasks can foster a deeper understanding and uncover better, more consistent solutions. Of course, another proposal can be created to revisit this topic, but that creates more churn. Formally reviewing overarching goals and all the aspects of achieving them could, in the long run, create a better product more efficiently and better involve and align the community.</div><div class=""><br class=""></div><div class="">This might slow down the rate of change in the language and libraries, but that is not necessarily a bad thing in something as complex as attempting to create a new language for a wide spectrum of applications.</div><div class=""><br class=""></div><div class="">This goal may be the exception, but the current process may not be optimal for complex multi-faceted problems that are on the horizon, like creating a metadata system, macros, kernel and driver software (?), ...</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 9, 2016, at 10:16 AM, Brandon Knope via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class="">I believe large syntax changes should have more discussion from more developers and not a very small subset of them. The review announcement needs to be broader: the swift blog needs to announce it so more people know.</span><br class=""></blockquote><span class=""></span><br class=""><span class="">No.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">Grrrr</div><br class=""><blockquote type="cite" class=""><div class=""><span class=""></span><br class=""><span class="">Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.</div><div class=""><br class=""></div><div class="">Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. <b class="">How is this enough? How is this enough variety?</b></div><div class=""><br class=""></div><div class="">Just because "announce" is more palatable does not mean that it is being used in the way you are describing. </div><div class=""><br class=""></div><div class="">Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class=""></span><span class="">The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 <b class="">unique </b>people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.</div><div class=""><br class=""></div><div class="">Getting feedback from the same <b class="">~10</b> people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.</div><br class=""><blockquote type="cite" class=""><div class=""><span class=""></span><span class="">I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.</span></div></blockquote><div class=""><br class=""></div><div class="">I think you will be very surprised come WWDC when people learn of this change.</div><div class=""><br class=""></div><div class="">How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest? </div><div class=""><br class=""></div><div class="">This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.</div><div class=""><br class=""></div><div class="">The bar <b class="">should </b>be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.</div><br class=""><blockquote type="cite" class=""><div class=""><span class=""></span><span class="">And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal. </span></div></blockquote><div class=""><br class=""></div><div class="">I don't think this was though through thoroughly enough. It just happened too fast</div><br class=""><blockquote type="cite" class=""><div class=""><span class="">Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.</span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.</div><div class=""><br class=""></div><div class="">And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.</div><div class=""><br class=""></div><div class="">How can us simpletons argue against that?</div><div class=""><br class=""></div><div class="">Also, I want to make clear that my concern is not just for this review but for future reviews also. <b class="">How different could the language look with more varied feedback?</b></div><div class=""><br class=""></div><div class="">Again, I hope I am wrong =/</div><div class="">Brandon</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><span class="">-- </span><br class=""><span class="">Brent Royal-Gordon</span><br class=""><span class="">Architechies</span><br class=""><span class=""></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>