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

Fri May 27 11:07:52 CDT 2016

> Am 27.05.2016 um 16:54 schrieb Matthew Johnson <matthew at anandabits.com>:
> 
>> 
>> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Personally I think `&` is more lightweight (and it is established in other languages like Ceylon and Typescript) and `where` is more expressive (and established in Swift for introducing constraints), so I would stay with these.
> 
> I agree.  If we can make `&` with `where` work syntactically it would be nice to go in this lighter weight direction.  If we decide to do that the question then becomes what to do with `protocol`.  Would it be feasible to replace it with `&` in Swift 3 if we decide on that direction?

Yep. `protocol` should be replaced with `&` in that case.

-Thorsten

> 
>> 
>> -Thorsten
>> 
>> 
>>> Am 27.05.2016 um 14:34 schrieb Vladimir.S <svabox at gmail.com <mailto:svabox at gmail.com>>:
>>> 
>>> Btw, in case we have `where` keyword in syntax related to types/protocols (when defining constrains. and not some symbol like '>>'.. don't know, for example), why we can't have 'and' keyword also when discuss the syntax of type/protocol conjunction?
>>> I.e.
>>> 
>>> let x: P and Q
>>> let x: P and Q where P.T == Q.T
>>> let x: P and Q and R
>>> 
>>> or, for consistency, as I understand it, we should have
>>> let x: P & Q >> P.T == Q.T
>>> 
>>> On 27.05.2016 11:55, Thorsten Seitz via swift-evolution wrote:
>>>> We could just write
>>>> 
>>>> let x: P & Q
>>>> instead of
>>>> let x: Any<P, Q>
>>>> 
>>>> let x: Collection where .Element: P
>>>> instead of
>>>> let x: Any<Collection where .Element: P>
>>>> 
>>>> let x: P & Q where P.T == Q.T
>>>> instead of
>>>> let x: Any<P, Q where P.T == Q.T>
>>>> 
>>>> let x: P & Q & R
>>>> instead of
>>>> let x: Any<P, Q, R>
>>>> 
>>>> let x: Collection
>>>> instead of
>>>> let x: Any<Collection>
>>>> 
>>>> 
>>>> This would avoid the confusion of Any<T1, T2> being something completely
>>>> different than a generic type (i.e. order of T1, T2 does not matter whereas
>>>> for generic types it is essential).
>>>> 
>>>> 
>>>> -Thorsten
>>>> 
>>>> 
>>>> 
>>>>> Am 26.05.2016 um 20:11 schrieb Adrian Zubarev via swift-evolution
>>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>>:
>>>>> 
>>>>> Something like |type<…>| was considered at the very start of the whole
>>>>> discussion (in this thread
>>>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016523.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016523.html>>),
>>>>> but it does not solve the meaning of an existential type and also might
>>>>> lead to even more confusion.
>>>>> 
>>>>> From my perspective I wouldn’t use parentheses here because it looks more
>>>>> like an init without any label |Type.init(…)| or |Type(…)|. I could live
>>>>> with |Any[…]| but this doesn’t look shiny and Swifty to me. Thats only my
>>>>> personal view. ;)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Adrian Zubarev
>>>>> Sent with Airmail
>>>>> 
>>>>> Am 26. Mai 2016 bei 19:48:04, Vladimir.S via swift-evolution
>>>>> (swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>) schrieb:
>>>>> 
>>>>>> Don't think {} is better here, as they also have "established meaning in
>>>>>> Swift today".
>>>>>> 
>>>>>> How about just Type(P1 & P2 | P3) - as IMO we can think of such
>>>>>> construction as "creation" of new type and `P1 & P2 | P3` could be treated
>>>>>> as parameters to initializer.
>>>>>> 
>>>>>> func f(t: Type(P1 & P2 | P3)) {..}
>>>>>> 
>>>>>> 
>>>>>> On 26.05.2016 20:32, L. Mihalkovic via swift-evolution wrote:
>>>>>> > How about something like Type{P1 & P2 | P3} the point being that "<...>" has an established meaning in Swift today which is not what is expressed in the "<P1,P2,P3>" contained inside Any<P1, P2,P3>.
>>>>>> >
>>>>>> >> On May 26, 2016, at 7:11 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >>> on Thu May 26 2016, Adrian Zubarev <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> wrote:
>>>>>> >>>
>>>>>> >>> There is great feedback going on here. I'd like to consider a few things here:
>>>>>> >>>
>>>>>> >>> * What if we name the whole thing `Existential<>` to sort out all
>>>>>> >>> confusion?
>>>>>> >>
>>>>>> >> Some of us believe that “existential” is way too theoretical a word to
>>>>>> >> force into the official lexicon of Swift. I think “Any<...>” is much
>>>>>> >> more conceptually accessible.
>>>>>> >>
>>>>>> >>>
>>>>>> >>> This would allow `typealias Any = Existential<>`. * Should
>>>>>> >>> `protocol A: Any<class>` replace `protocol A: class`? Or at least
>>>>>> >>> deprecate it. * Do we need `typealias AnyClass = Any<class>` or do we
>>>>>> >>> want to use any class requirement existential directly? If second, we
>>>>>> >>> will need to allow direct existential usage on protocols (right now we
>>>>>> >>> only can use typealiases as a worksround).
>>>>>> >>
>>>>>> >> --
>>>>>> >> Dave
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> swift-evolution mailing list
>>>>>> >> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>> > _______________________________________________
>>>>>> > swift-evolution mailing list
>>>>>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>> >
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/0d996d2e/attachment.html>