<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Thanks for the thoughtful feedback :)</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I partially agree with you on Accepted with Revision...however this could potentially slow down things significantly. I think syntax changes should work the way you describe however as they are more far reaching.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I still love Swift, I am just stung by the loss of some of its character for the sake of consistency. But it is not the end of the world. I just worry about the future if we don't get more varied feedback.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I would love for where to have a place with its expressivity, but I doubt it at this point. My concern has more to do with the little feedback we get from the community with some of these big changes</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Brandon<br><br>Sent from my iPad</div><div><br>On Jun 9, 2016, at 12:53 PM, Ethan Eberle <<a href="mailto:ethandeberle@gmail.com">ethandeberle@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><div id="AppleMailSignature">Hi Brandon –</div><div id="AppleMailSignature"> </div><div id="AppleMailSignature">I’ll try to speak for one of those ‘newer’ developers (I’ve only got ~1 year of experience in dev work and it’s all part time as a hobby), although my views obviously only reflect my own.</div><div id="AppleMailSignature"> </div><div id="AppleMailSignature">I also had a similar ‘gut’ reaction to the approval but after re-reading it several times the change is surprisingly minor. At its core, the proposal just involves adding extra ‘lets’ and ‘cases’ to the syntax. I think this is a great solution that avoids the need for semi-colons or some new delimiter (I first learned to code in Python and semicolons are anathema in my mind). It also removes the arbitrary use of “where” (I didn’t even know this was possible). I’d prefer we allow the use of “where” when the constraint applies only to the unwrapped item immediately preceding it, but such is life [1]. (Core Team – I’ll look forward to reading the revised accepted proposal, I’m still confused about a few of the details).</div><div id="AppleMailSignature"> </div><div id="AppleMailSignature">In terms of the broader review process, it’s predicated upon users providing timely feedback during the official review period – which went on for the proscribed time. The core team clearly put much thought into this since it took longer than usual, on balance, to announce their decision. I would add that the only time an accepted proposal should be ‘overturned’ is if the implementation turns out to be too complicated or if there were other downstream affects that weren’t previously discovered in the review process (we’ve already seen a bit of this). If everything is continually revisited, then there will be next to no forward progress.</div><div id="AppleMailSignature"> </div><div id="AppleMailSignature">That said, the one process improvement I have is that proposals should ideally only be “Accepted” by the core team as it is originally written (or with relatively minor changes) or completely “Rejected”. The “Accepted with Revision” approach can result in new ideas being approved but not being fully vetted by the community. This also eliminates needless "surprises", which is always good. Proposal are either accepted or rejected, nothing in between. I actually think this approach is win-win for the core team and the community – although the ultimate decision to reject or approve a proposal must rest with the Core Team. For this reason, I think in this case it *might* be tenable to “re-visit” this proposal (say, after WWDC) once Chris puts the accepted version's language on GitHub. It could also be evaluated within the broader context of removing (or retaining) 'where' elsewhere in the language (see Erica's proposal), though for scoping purposes the proposals should remain separate. If it is re-visited, I’m no compiler/language expert but it seems like you could unambiguously permit the use of ‘where’ in the specific cases I mentioned earlier. It’s purely syntactic sugar and “burns” a keyword but is a nice optional expressivity feature, and I remember seeing some Core Team members showing interest in it. Maybe this approach is the best of both worlds? :D</div><div id="AppleMailSignature"> </div><div id="AppleMailSignature">“I just wanted to express my concerns for a language I was growing to really love!”</div><div id="AppleMailSignature"> -> Hopefully you’ll continue to love it :)</div><div id="AppleMailSignature"> </div><div id="AppleMailSignature">Just my two cents,</div><div id="AppleMailSignature">Ethan</div><div id="AppleMailSignature"> </div><div id="AppleMailSignature">[1] Swift is indeed an opinionated language.</div><br><div><br></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.294118);">Sent from my iPhone.</span></div></div><div><br>On Jun 9, 2016, at 12:35 PM, L. Mihalkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div><br>On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><br>Sent from my iPad</div><div><br>On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br><br></div><blockquote type="cite"><div><blockquote type="cite"><span>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></blockquote><span></span><br><span>No.</span><br></div></blockquote><div><br></div><div>Grrrr</div><br><blockquote type="cite"><div><span></span><br><span>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></div></blockquote><div><br></div><div>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></blockquote><div><br></div><div>But if you followed the email trail you must have noticed that the final choice was not what brent supported. I would even say that it was not any of the solutions anyone proposed.. Proof that the process worked, the team made a change nobody anticipated, yet many people can (partially) identify with. </div><br><blockquote type="cite"><div><div><br></div><div>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>How is this enough? How is this enough variety?</b></div><div><br></div><div>Just because "announce" is more palatable does not mean that it is being used in the way you are describing. </div><div><br></div><div>Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.</div><div><br></div><blockquote type="cite"><div><span></span><span>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></div></blockquote><div><br></div><div>Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 <b>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><br></div><div>Getting feedback from the same <b>~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><blockquote type="cite"><div><span></span><span>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><br></div><div>I think you will be very surprised come WWDC when people learn of this change.</div><div><br></div><div>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><br></div><div>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><br></div><div>The bar <b>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><blockquote type="cite"><div><span></span><span>And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal. </span></div></blockquote><div><br></div><div>I don't think this was though through thoroughly enough. It just happened too fast</div><br><blockquote type="cite"><div><span>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></div></blockquote><div><br></div><div>Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.</div><div><br></div><div>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><br></div><div>How can us simpletons argue against that?</div><div><br></div><div>Also, I want to make clear that my concern is not just for this review but for future reviews also. <b>How different could the language look with more varied feedback?</b></div><div><br></div><div>Again, I hope I am wrong =/</div><div>Brandon</div><div><br></div><br><blockquote type="cite"><div><span>-- </span><br><span>Brent Royal-Gordon</span><br><span>Architechies</span><br><span></span><br></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></body></html>