[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[L. Mihalkovic]

> On May 25, 2016, at 10:01 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I am not going to comment on the proposal (conflict of interest etc). I do want to speak up in support of Brent's points, though.
> 
>>> On May 25, 2016, at 12:34 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>    * What is your evaluation of the proposal?
>> 
>> I am in favor. This is a necessary step towards many future features: class-plus-protocol types, the replacement/reimplementation of AnyObject with Any<class>, existentials with associated types, etc.
>> 
>> One reason to prefer `Any` over `any` which is not listed in the proposal is confusion with the unparameterized `Any` type. Having an uppercase `Any` and a lowercase `any<…>` is going to lead to a lot of confusion; people aren't going to remember whether they need the capitalized form or the lowercase one for any particular use. I don't think we can have `any<...>` unless we're also willing to have an unparameterized `any`, and I think `any` is 100% wrong, because it is absolutely a type but is lowercase.
>> 
>> Since we are trying to cram as many breaking changes as possible into Swift 3, I also think we should consider now, or soon, whether or not we want to draw a strong syntactic line between protocols-as-existentials and protocols-as-constraints by requiring the use of `Any<…>` on all existentials and forbidding its use in constraints. That would mean, for instance, that code like this:
>> 
>>    let printable: CustomStringConvertible = foo
>> 
>> Would now be written:
>> 
>>    let printable: Any<CustomStringConvertible> = foo
> 
> I'm sure this will be controversial, but I like the idea of marking all existential types using Any-syntax. It makes the distinction between concrete and existential types in code completely clear to the reader. Given that there are some subtle differences in how concrete and existential types can be used (for example, used as the types of values passed to generic functions), I think this is definitely worth considering.
> 

Much of what I read about the swift philosophy seems to boil down to immediate association of the semantic with the syntax, to help the newcomer 'parse' the language in their mind with less efforts. Seems to me that Any<> being so close to Array<> could be construed as running counter to that philosophie.

> There are an additional five characters (including two angle brackets to type), but I suspect bare existentials aren't used quite as often as concrete types are, so the aesthetic cost might not be too onerous.
> 
>> 
>> And also that code like:
>> 
>>    func foo<X: Any<Y, Z>>(x: X)
>> 
>> Would probably have to be written something like:
>> 
>>    func foo<X: Y>(x: X) where X: Z
> 
> I also personally prefer this convention. The 'Any<Y, Z>' construct in the constraint above does not really have anything to do with existential types as they exist everywhere else in Swift; it simply means that whatever concrete type can be used to instantiate the function must conform to two different protocols.
> 
> It's true that any concrete type that could be used to satisfy X in foo() could also be used to fill an Any<Y, Z> existential, but this correspondence isn't interesting to the user. The ways a user can use an Any<Y, Z> existential differ from the ways a sort-of-universal type like X in foo() can be used:
> 
> // firstElement's type is known exactly at compile time, because X must be 'filled in'
> // by a concrete type, and that concrete type's associated types are also known.
> foo<X : Collection>(x: X) {
>  let firstElement : X.Iterator.Element = x.first!
> }
> 
> // firstElement's type is not ever known without some sort of dynamic downcasting,
> // because the contract that defines the existential can guarantee nothing about its type.
> let foo : <X : Collection> = ...
> let firstElement : Any = x.first!
> 
>> 
>> However, I believe this would have a significant advantage: it would clarify the distinction between an existential and a constraint. It would more clearly mark where you are taking on the abstraction overhead of an existential. It would also improve the non-existential type situation: in the short term, it would make it clearer where uses of associated type protocols like `Comparable` would not be permitted; in the long term, once we have type-erased existentials for those protocols, it would make it clearer when type erasure was in effect.
>> 
>>>    * Is the problem being addressed significant enough to warrant a change to Swift?
>> 
>> Yes. `protocol<>` is an ugly and unloved corner of the language; very few people know about it, remember it, or use it. The renaming improves this situation.
>> 
>>>    * Does this proposal fit well with the feel and direction of Swift?
>> 
>> Given the way it enables many future features, yes.
>> 
>>>    * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 
>> The only language I've used with similar features is Objective-C. There, too, the `<>` is overloaded, now that lightweight generics are part of the language.
>> 
>>>    * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> I'd like to think I have a fairly deep understanding of this feature, having participated heavily in the discussions about it.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution