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

[Matthew Johnson]

> On May 27, 2016, at 3:57 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
> 
>> 
>> Am 25.05.2016 um 17:03 schrieb Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>> 
>>> On May 25, 2016, at 9:59 AM, L. Mihalkovic via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> 
>>>> On May 25, 2016, at 10:01 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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 philosophy.
>> 
>> This is a big part of the case for using lowercase `any`.  But there are good arguments on both sides.  In Joe’s hypothetical future Swift, `Any` would be a standard library type thus it wouldn’t have such a strong difference from Array.
> 
> The difference stems from the fact that the order of parameters does not matter in `Any` whereas it is essential for generic types.
> Would this be changed by Joe’s vision?

I’m not sure.  Hopefully Joe can answer.  

I agree that indifference to order is important here and is an important difference from the generic types we have today.

> 
> -Thorsten

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/fe863b60/attachment.html>