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

[Tony Allevato]

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