I have just one last thing to say on this topic as it is clear it is going into the language and no accepted proposal has been overturned that I am aware of.
I believe with this cycle, the swift evolution process didn't work. And here is why I think this: - This proposal began as a discussion on May 20th and lasted 4 days with minimal discussion outside of a few people - The review period was then fast tracked and began 3 days after discussion ended (May 27th) - The review period technically ended on June 3rd - Approved with revision on June 8th >From May 20th to June 8th (and probably before because it was clear this was >getting approved earlier) we have proposed, revised, and accepted a far >reaching syntactic change. Presumably we will be stuck with this behavior for >a long time or forever. This effects more than just the few that participated >in the discussion: it effects every swift user. I think this happened too fast. I do not believe we got an adequate pulse of the broader swift community. What we got was very technical and proficient user feedback. When phrases like "making the language more consistent", why wouldn't these developers want to approve it? This is the kind of stuff people deeply involved in the language care about. I am not sure that reflects the entire community. What about the more common developer who isn't as technically skilled yet? This has huge changes for them too and I barely heard any of their voices...at least publicly. This has big usability changes for them. On top of this, we have a new revised syntax that somewhat meets in the middle of both sides. However, does meeting in the middle make this all better just for the sake of consistency? Should we have an extended review period for this proposed change or do we just accept it? My TLDR overview: - Discussion and proposal moved extremely fast. We only heard feedback from the more proficient developers and not necessarily the "common" developer...which this arguably effects more. The technically skilled can always adapt and of course always prefers a more consistent language...but do most developers feel this way? They just want a usable and expressive language - WWDC is in a few days. We will get a flood of people from all different backgrounds: newbies to the very skilled. My prediction: there will be backlash from this proposal once more people know about it. 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. Not everyone is on the mailing list...because frankly it can be daunting for us who aren't as skilled as the others on here. Do I believe that the smartest people can design a great language on their own? No. It is generally understood that most developers don't fully understand UX or the end users using their stuff. I feel this is what has happened with this proposal. It sounded good because it was all for the sake of "consistency". However, I believe the end user will ultimately be disappointed with the loss of expressivity. Maybe I am wrong. I hope I am wrong...but I feel we will not here the end of this after WWDC begins. And because of that, this is why I feel the swift evolution process did not work properly in this case. (And really I have this same with other fast tracked proposals now). Really TLDR: I believe these large syntax proposals need broader feedback from the community and not a small subset of the top swift developers. How do we pull more people in for these discussions? I don't know, but more announcements on the blog and from Swift on Twitter Sorry for the long post, but I just wanted to express my concerns for a language I was growing to really love! Brandon Sent from my iPad > On Jun 9, 2016, at 3:53 AM, Haravikk via swift-evolution > <[email protected]> wrote: > > >> On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution >> <[email protected]> wrote: >> >> comma should remain the condition separator, and the 'where' keyword can be >> retired from its purpose as a boolean condition introducer. > > Can we get some clarification as to why ‘where’ is being chosen to be retired > here? I’m deeply disappointed by that decision as enabling the consistent use > of comma as a separator does not preclude the use of where for simple cases > that don’t require it. I’m all for having a more usable separator for complex > conditionals, but I rarely need it, meanwhile in common, simple conditional > bindings and patterns I find the ‘where’ keyword a lot more readable, i.e: > > if let value = foo where foo > 5 { … } > if let value = foo, foo > 5 { … } > > The latter just doesn’t read as cleanly to me, and these are the kinds of > simple conditionals that I use a lot of. As such as I’d still prefer to have > ‘where’ be usable in the simple case, and I feel it was a mistake for the > SE-0099 to have it tied to changes to the separator as the two changes aren’t > mutually exclusive. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
