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

[Thorsten Seitz]

> Am 14.05.2016 um 17:52 schrieb Tony Allevato via swift-evolution <swift-evolution at swift.org>:
> 
> 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.

IMO the readability is improved because the where clause can be easily placed in a new line. Generic function definitions with where clauses typically are too long for being crammed into one line without having the readability suffer. The proposal allows a much more readable splitting of the definition into several lines. This completely alleviates the problem of separating generic type information or sandwiching the return type, because the where clause in the next line will be near the generic type parameter list again.
Taking Jon Shier’s example: 
The following definition is already too long IMO. The current syntax does not allow nice splitting of the line and readability suffers from the long gap between the function name and its parameter list:
    func something<T: Decodable where T == T.DecodedType>(with something: T) -> String

instead of writing a long line with sandwiching problems like that:
    func something<T: Decodable>(with something: T) -> String where T == T.DecodedType

I would write:
    func something<T: Decodable>(with something: T) -> String 
        where T == T.DecodedType


To recap: I think that readability improves with the proposal for the following reasons:
- The gap between the function name and its parameter list is reduced
- Definitions with where clauses typically are already too long to readably fit into one line, so they should be split over more than one line. The current syntax does not offer a natural position for a line break (breaking before the where even further increases the gap between the function name and its parameter list and it looks ugly because of the angle brackets being on separate lines.

-Thorsten

> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160516/978b3f5c/attachment.html>