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

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:

  swift-evolution/0081-move-where-expression.md at master · apple/swift-evolution · GitHub

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

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

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

  * Is the problem being addressed significant enough to warrant a change to Swift?

yes

  * Does this proposal fit well with the feel and direction of Swift?

yes

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

n/a

  * 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 email chain

···

On May 10, 2016, at 11:51 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

* What is your evaluation of the proposal?

Strong assent.

* Is the problem being addressed significant enough to warrant a change to
Swift?

Lots of people have complained about heavily parameterized generic code
being difficult to read and rather scary looking in general. While this
proposal makes no changes to the expressiveness of the language, it
improves developer ergonomics and helps keep people's eyes from glazing
over when they try reading through such functions.

* Does this proposal fit well with the feel and direction of Swift?

No loss of expressive power, an improvement overall. (There is also a
pleasing symmetry with the 'where' clause syntax for protocol extensions.)
It feels more natural: the most important information (name, generic type
parameter decls, formal parameters, and return type/effects) are all
introduced to the reader before the subordinate constraint clause is
introduced with 'where'. Before, the angle brackets portion of a function
declaration could become a huge multi-line symbol-rich blob separating the
function name from the parameters/return type, making it harder to visually
parse.

* If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I believe Rust does something similar. This is probably another advantage,
a tiny bit of friction removed from people who want to move between these
two languages.

* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

Close reading of the proposal; followed along within the proposal thread.

Best,
Austin

···

On Tue, May 10, 2016 at 11:51 AM, Chris Lattner <clattner@apple.com> 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:

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

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

Yes please.

It is significant enough to warrant a change to Swift. Folding generic argument lists — Erica Sadun
It fits with the feel and direction of Swift. It makes Swift easier to format, read, and maintain. I particularly like that the type arguments are declared and used first, then constrained later. It feels like a more natural placement.
I have incited discussion on this, followed it from the start, and have been an excited cheerleader along the way.

-- E

···

On May 10, 2016, at 12:51 PM, Chris Lattner via swift-evolution <swift-evolution@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:

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

  * What is your evaluation of the proposal?

+1. I think including constraints in the generic parameter list is clunky. I am happy to see it move.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. It significantly increases clarity IMO.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed the discussion and read the proposal.

···

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-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

Although handy for now, I am a bit concerned about moving `where` clause to the end of declaration. This reserves and occupies this wide open space at the end of declarations. I think we might find a better use for this space later as the language evolves. Any thoughts?

···

On May 10, 2016, at 11:51 AM, Chris Lattner via swift-evolution <swift-evolution@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:

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

- What is your evaluation of the proposal?
   - All the +1s. This is more consistent with `where` clauses elsewhere in
      the language and is much more readable.
   - Is the problem being addressed significant enough to warrant a change
   to Swift?
   - Yes.
   - Does this proposal fit well with the feel and direction of Swift?
   - Yes. Consistent and readability have been very important with Swift so
      far.
   - If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
   - Rust is similar.
   - 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 discussions.

···

On Tue, May 10, 2016 at 2:51 PM, Chris Lattner via swift-evolution < swift-evolution@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:

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

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

What is your evaluation of the proposal?
A big +1
  
Is the problem being addressed significant enough to warrant a change to Swift?
Yes. This makes it much more natural to read methods and functions with generics. This also makes it more predictable to find where the method signature is without having to weed through a bunch of generic constraints.

Does this proposal fit well with the feel and direction of Swift?
Most definitely. Feels more natural and consistent with other uses of `where`

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve followed the evo thread since the beginning

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

   * What is your evaluation of the proposal?

+1

   * Is the problem being addressed significant enough to warrant a change to Swift?

I'll reserve that to others with a deeper understanding of the effect of this change.

   * Does this proposal fit well with the feel and direction of Swift?

I find the declarations with the where clause at the end so much easier to read and understand. For that reason alone I am In favor of this change.

This definitely goes well with what I expect of Swift. I love Swift's conciseness and expressiveness. This would continue to improve in that respect.

   * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Compare to other languages I think this would make Swift superior in regards to clarity of declarations.

   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading.

···

On May 10, 2016, at 2:51 PM, Chris Lattner <clattner@apple.com> wrote:

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-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

  https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md

  * What is your evaluation of the proposal?

+1, I like the syntax and think it can clean up some parser ambiguities.

Today, there are several formats using angle brackets:
- a parameter declaration as an ordered dictionary of names to type or type-decensent restrictions (or Any if not specified)
- an argument declaration as an ordered list of concrete types
- an unordered list of required protocol conformances

Eliminating the where clause sometimes available in parameter declarations simplifies understanding the generic syntaxes.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes

  * Does this proposal fit well with the feel and direction of Swift?

Yes, although I don’t know how it evaluates against possible future syntax for the generics manifesto feature lists

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

Followed discussion

-DW

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

  * What is your evaluation of the proposal?

+1

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Although this is (IIUC) syntax sweetener so needs to be prioritized with other changes.

  * Does this proposal fit well with the feel and direction of Swift?

Yes. The given example does look more readable and I can’t think of a situation where it becomes less readable. Generics are difficult so anything that makes them easier to approach is welcome. The fact that there is now greater consistency with extension declarations is also +1.

There was an objection raised that it would close the door on a future features or types of constraint. It is difficult for me to evaluate that, but the consensus seemed to be it could be handled with additional syntax and possible keywords. The consistency and readability for these more common cases should be prioritized IMO.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

This morning. Read proposal, pitch and current review thread. [Tried to parse the proposed grammar changes, but didn’t spend a lot of time with it.] Thanks to the authors and contributors for thinking about this stuff and pushing it forward.

* What is your evaluation of the proposal?
+1

More readable.

* Is the problem being addressed significant enough to warrant a change to Swift?
Yes. Current form of defining requirements makes deciphering the signatures with high number of requirements a logical riddle.

* Does this proposal fit well with the feel and direction of Swift?
I do think so. It’ll further encourage the use of generics, which I see as one of the cornerstones of Swift.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Not that I can think of, but now I’d like to see similar change in Scala :)

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I’ve read proposal and corresponding discussion.

All the best,

Krzysztof

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

  * What is your evaluation of the proposal?

+1

It increases readability of generics by a far margin.
I appreciate that the proposal allows to pull out the inheritance/conformance constraints into the where clause, too, very much!

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, as more complex generics are a powerful feature of Swift and the increased readability helps designing and using them very much.

  * Does this proposal fit well with the feel and direction of Swift?

Absolutely.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Ceylon uses a similar syntax to declare the constraints of generic parameters:
shared interface DirectedGraph<V,E> satisfies IncidenceGraph<V,E>
      given V satisfies Object
      given E satisfies DirectedEdge<V, E> { … }
I always found this very readable but with Swift’s ability to declare constraints between associated types of generic parameters this is even more important.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal carefully and followed the discussion.

-Thorsten

···

Am 10.05.2016 um 20:51 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:

  * What is your evaluation of the proposal?

I’m a +1, however personally I’d prefer this to be optional my constraints aren’t that complex, for example:

  func someMethod<T where T.Element == String>(value:T) { … }

Personally I prefer to keep such simple cases as they are, but would happily use the new ability to move more complex ones (e.g- dealing with Generator.Element and multiple constraints) to the end as proposed.

So I’m +1, but I don’t think it should be one or the other, I’d prefer to have both options, with a recommendation that trailing constraints be used in complex cases for clarity.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Generic constraints are one of the most powerful, and daunting, features of Swift, so anything that makes them a bit neater and keeps function signatures tidy is an improvement. Of course there’s a lot more that can be done to simplify generic constraints further, but given the simple elegance of this improvement it easily justifies inclusion.

  * Does this proposal fit well with the feel and direction of Swift?

I’d say yes, since the feature itself is unchanged and already part of Swift, it’s just the location that is being moved.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read through, which is plenty since the proposal is fairly straightforward, I’ve also been following the discussion for a while.

···

On 10 May 2016, at 19:51, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

-1

No one has been able to explain how this change improves readability, it just seems like it’s supposed to be self evident. I would argue that it makes the generic definitions less readable by separating declarations and their relevant where clauses. At best this change just moves the already unreadable mass of text elsewhere, where it’s still unreadable. Furthermore, it trades this supposed readability of generic parameters for decreased readability of the actual function signature, since that signature’s now buried between the generic definitions and the where clauses. This is especially bad when declaring a single generic type that can easily fit on a single line, such as:

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

turns into this, which is less readable to me, as it hides important information between the generic information:

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

Also, this proposal doesn’t explain how the definitions for generic types would change. Using the proposed grammar would be even worse on types. From:

final class NetworkOperation<T: Decodable where T == T.DecodedType>: Operation,… {

to:

final class NetworkOperation<T: Decodable>: Operation,… where T == T.DecodedType {

The additional conformances types can have make this an especially bad use case for this proposal.

  * Is the problem being addressed significant enough to warrant a change to Swift?

It can be a problem, but I don’t see how this proposal fixes it. Appropriate code styling, whether manual or provided by an IDE, could provide much better readability than this proposal ever could.

  * Does this proposal fit well with the feel and direction of Swift?

Changes proposed for “readability” need to be closely scrutinized, as one programmer’s readable and another’s Perl. I don’t think this proposal meets the high standard this list has tried to set for things to the language.

  * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Java and C++’s generics, which are rather different. And despite what they may have intended, I don’t think generics in either language are used as much as in Swift.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal, the thread thus far, and considered my response.

Jon

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.

···

On 2016-05-10 18:51:29 +0000, Chris Lattner via swift-evolution said:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

  * What is your evaluation of the proposal?

-1

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More than a quick reading, but not really “in-depth” study…

* Does this proposal fit well with the feel and direction of Swift?

I don’t really think it does. I don’t remember anything in Swift that went through such a bizarre change just because it looks ugly.

I mean, the where clause isn’t a comment; it’s not documentation. It’s absolutely vital to anybody and everybody who uses anything with one. Really, I can’t see any logic to splitting the parameter name and constraints. It’s completely baffling, and if it wasn’t that they’re “ugly” I don’t think anybody would give this proposal a second thought. Besides, when I need to look up which parameters I need for a type, it’s nice to have them all in one place in a clearly delimited section of the declaration.

* Is the problem being addressed significant enough to warrant a change to Swift?
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I’m with Jon Shier on this - it is a problem, but it’s one inherent to generics. In some languages, you have great big whoppers for type parameters and have to pass them around everywhere you go; we’re relatively clean with Swift. Nobody writing swift should complain about our type parameters being too messy:

interface Feeder<F extends Food, A extends Animal<F,?>, S extends Store<F>> {
  public void buyFoodAndFeed(A animal, S store);
}
class StoreFeeder implements Feeder<Grass, Animal<Grass, ?>, Store<Grass>> {
  public void buyFoodAndFeed(Animal<Grass, ?> animal, Store<Grass> store) {
    animal.eat(store.buyFood());
  }
}

I have a counter-proposal to tackle the readability issue: that we extend SE-0048: Generic Typealiases [1] to include where clauses. The proposal already mentions this, and simply says "If there is a compelling reason to add this, we can consider extending the model to support them in the future, based on the merits of those reasons.” If we did that, we could drastically shorten function/class declarations - using, say, “StringCollection” or “IntegerSequence” rather than <C:Collection where C.Iterator.Element==String>.

[1](https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md\)

···

On 10 May 2016, at 20:51, Chris Lattner via swift-evolution <swift-evolution@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:

  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:

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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

* What is your evaluation of the proposal?

-1.

I'm in strong agreement with what Karl Wagner and Jon Shier said.

The current 'where' syntax seems perfectly fine to me. It puts the
constraints in the logical place, next to the type declarations, which is
clear and intuitive.

The proposed change seems akin to declaring a variable:

var x

and then, several lines later, after unrelated code, specifying its type:

where x: Int

I can't see the advantage in doing that.

Yes, the 'where' statements can get long, but that's because they need to
express complex constraints. Moving them to a different place doesn't make
them any shorter, it just makes the problem less apparent by sweeping the
dirt under the carpet.

To make the 'where' statements better, what we need to do is make them
simpler. To do that, we need to reduce the complexity of the constraints
that need to be specified in a declaration.

The most obvious ways to do that are:
* add generic constraints to associatedtype;
* support typealias in protocols;
* add generic constraints to typealias.

Those improvements would allow to break up the complexity, making the
'where' clauses in declarations much shorter and simpler.

protocol Collection {
    associatedtype Iterator: IteratorProtocol
    typealias Element = Iterator.Element
    associatedtype SubSequence: Sequence where SubSequence.Element == Element
}

typealias SortableCollection = protocol<Collection> where
Collection.Element: Comparable

being able to use the above constructs would go a long way to making the
'where' clauses simpler without needing to change their syntax.

* Is the problem being addressed significant enough to warrant a change to

Swift?

Yes, but the proposed change seems to do little to actually address the real
problem.

* Does this proposal fit well with the feel and direction of Swift?

Swift excels at being terse and focused. The proposed change doesn't improve
terseness and reduces focus by putting related information in two different
places. So I don't think it is going in the right direction.

* If you have used other languages or libraries with a similar feature,

how do you feel that this proposal compares to those?

I can't think of anything similar to this.

* How much effort did you put into your review? A glance, a quick reading,

or an in-depth study?

A full reading of the proposal, a quick reading of the relevant threads, and
careful thought about the issue and my experience using Swift's type system.

Nicola

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

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

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

* What is your evaluation of the proposal?
+1
        * Is the problem being addressed significant enough to warrant a
change to Swift?
yes
        * Does this proposal fit well with the feel and direction of Swift?
yes
        * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
It is on par with constraint declarations/relations in other languages
        * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
quick reading but I have been following the discussions that this came out
of.

···

On Tue, May 10, 2016 at 2:42 PM, Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote:

> On May 10, 2016, at 11:51 AM, Chris Lattner via swift-evolution < > swift-evolution@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:
>
>
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 much much readable
> * Is the problem being addressed significant enough to warrant a
change to Swift?
yes
> * Does this proposal fit well with the feel and direction of Swift?
yes
> * If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
n/a
> * 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 email chain
>
> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution