[swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Patrick Smith]

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 <swift-evolution at swift.org> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution