[swift-evolution] [Review] SE-0081: Move where clause to end of declaration
plxswift at icloud.com
Tue May 17 08:58:47 CDT 2016
Late, but +1 *overall*.
For function signatures I am somewhat indifferent, honestly; I think having the option to move part of the `where` clause after the signature declaration is beneficial, but not hugely so.
The reasoning here is simple: currently functions look like `func $name<$genericParameters>($args) -> $result`, and even though it’s difficult to *read* a lengthy `$genericParameters` the `($args) -> $result` portion (e.g. signature) isn’t "broken up". It’s good that it’s not broken up, but it means for *functions* the proposal is making only a minor readability improvement (by moving the “signature" closer to the “name”).
But, I think we have a *significant* improvement here for *type* declarations — classes, structs, etc. — because they look like e.g. this for classes: `class $name<$genericParameters> : $base (, … $protocols )`. If one is writing classes that use a lot of generic parameters with a lot of relationships between their associated types, the key parts of the type declaration wound up “split up” b/c the `$name` is very far away from the `$base`.
It’s apparently a somewhat-uncommon use but it’s *a lot nicer* under this proposal than under current syntax.
I wouldn’t object if the proposal tried to be a bit less flexible and e.g. forced all `:`-style constraints into the initial `<>` segment and all `where X.Y == Z.Q`-style constraints into the subsequent `where` clause, but I also don’t feel that that would be an unqualified improvement.
> On May 10, 2016, at 1:51 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 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?
> * Is the problem being addressed significant enough to warrant a change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 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