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

Fri May 27 11:13:18 CDT 2016

Sent from my iPad

> On May 27, 2016, at 11:07 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
> 
> 
>>> 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> 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.

Right, but it's a much larger syntax change.  If we decide on that direction and it's not feasible for Swift 3 I suppose we would just leave 'protocol' alone until Swift 3.x or 4.

> 
> -Thorsten
> 
> 
>> 
>>> 
>>> -Thorsten
>>> 
>>> 
>>>> Am 27.05.2016 um 14:34 schrieb Vladimir.S <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>>:
>>>>>> 
>>>>>> 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>),
>>>>>> 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>) 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>> wrote:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>> on Thu May 26 2016, Adrian Zubarev <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>
>>>>>>> >> 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
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>>> 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
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/bc585043/attachment.html>