[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>
matthew at anandabits.com
Tue May 24 13:29:57 CDT 2016
> * What is your evaluation of the proposal?
+1. This proposal pages the way for generalized existentials by getting the breaking change out of the way.
I encourage careful consideration of issues surrounding whether this proposal should retain the lowercase keyword convention with 'any', matching the current lowercase 'protocol' or not.
The argument for adopting uppercase is primarily that existentials are often used as types and type names are uppercase by convention.
My opinion tends towards retaining lowercase primarily because uppercase 'Any' looks like generic type but behaves differently. While there is some overlap, it cannot be used in all of the syntactic forms that generic types can, and it can be used in syntactic locations where generic types cannot. I believe this rules out the "fits into a syntactic slot" exemption for lowercasing keywords. Such an exemption should only apply when keywords are used in a way that is indistinguishable from user-defined constructs (such as dynamicType).
Another argument for upper case is the idea that we will directly use existentials in place of current type erased wrappers. I would prefer to see us establish the practice of declaring typealiases for commonly used existentials (which will quickly become verbose if used directly everywhere in out code).
The example given is 'Any<Sequence where .Element == String>'. I would prefer to see:
typealias AnySequence<T> = Any<Sequence where .Element == T>
This allows us to continue saying 'AnySequence<String>' in our code. This is a relatively simple constrained existential and yet I believe it reads much better than the raw existential. The difference will be quite significant with more complex existentials.
> * Is the problem being addressed significant enough to warrant a change to Swift?
Yes. 'protocol<>' doesn't feel like the right syntax for generalized existentials.
> * 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?
I don't believe I have.
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In depth study and participation in the discussion.
> More information about the Swift evolution process is available at
> Thank you,
> -Chris Lattner
> Review Manager
> swift-evolution-announce mailing list
> swift-evolution-announce at swift.org
More information about the swift-evolution