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

Nicola Salmoria nicola.salmoria at gmail.com
Sat May 14 09:38:49 CDT 2016


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




More information about the swift-evolution mailing list