[swift-evolution] [Review] SE-0081: Move where clause to end of declaration
tony.allevato at gmail.com
Sat May 14 10:52:21 CDT 2016
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:
> Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> 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
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
> * 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
> Thank you,
> -Chris Lattner
> Review Manager
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution