> Am 14.05.2016 um 17:52 schrieb Tony Allevato via swift-evolution
> <[email protected]>:
>
> 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
>> [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
