I tend to agree with Jon Shier, Karl Wagner, Nicola Salmoria, and Tony Allevato. I think moving `where` to the end hinders comprehension. The extra constraint abilities that Nicola brought up look interesting.
> On 15 May 2016, at 1:52 AM, Tony Allevato via swift-evolution > <[email protected]> wrote: > > On 2016-05-10 18:51:29 +0000, Chris Lattner via swift-evolution said: > >> Hello Swift community, >> The review of "SE-0081: Move where clause to end of declaration" begins now >> and runs through May 16. The proposal is available here: >> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md >> Reviews are an important part of the Swift evolution process. All reviews >> should be sent to the swift-evolution mailing list at >> https://lists.swift.org/mailman/listinfo/swift-evolution >> or, if you would like to keep your feedback private, directly to the review >> manager. >> What goes into a review? >> The goal of the review process is to improve the proposal under review >> through constructive criticism and contribute to the direction of Swift. >> When writing your review, here are some questions you might want to answer >> in your review: >> * What is your evaluation of the proposal? > > -1. My thoughts essentially mirror those of Jon Shier, Karl Wagner, and > Nicola Salmoria. > > To me, this makes declarations with complex sets of constraints much harder > to read, because I have to hunt them down instead of finding them all in one > place. Under this proposal, the longer an argument list gets, the further > separated the constraints are from the type parameters that use them. > > This solution also obfuscates function definitions. Having the function's > return type be the very last thing in the header line is has very nice > readability benefit, and this proposal takes that away by sandwiching the > return type awkwardly in the middle. > > The admission that some constraints should be allowed inside the angle > brackets (conformance constraints) while moving others (associated type > constraints) out introduces inconsistency in the language and seems like an > incomplete fix. From a teaching point of view, I would find it more difficult > to explain to users of the language "constraints that look like *this* go > here, but constraints that look like *that* go way over there". The current > model of "all generic constraints go between < and >" is clean and simple. > > Lastly, from a bit of a pedantic point of view, moving the where-clause to > the end of a function declaration makes it look like the function is > satisfying some constraints, when it's actually the generic type parameters > that are satisfying them. In that sense, it's better to keep them closer > together. > >> * Is the problem being addressed significant enough to warrant a change >> to Swift? > > Yes, but not in this fashion. I agree with some of the other sentiment that > there should be better ways of satisfying complex constraint sets (through > generic typealiases or something else) to clean them up, but moving the > where-clause creates more readability problems than it solves. > >> * Does this proposal fit well with the feel and direction of Swift? > > I don't believe so; it adds inconsistency rather than removes it. > >> * If you have used other languages or libraries with a similar feature, >> how do you feel that this proposal compares to those? > > No languages that allow generics to be expressed so richly as Swift's. > >> * How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? > > Read the proposal and followed the mailing list threads. > >> More information about the Swift evolution process is available at >> https://github.com/apple/swift-evolution/blob/master/process.md >> Thank you, >> -Chris Lattner >> Review Manager >> _______________________________________________ >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
