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

Matthew Johnson matthew at anandabits.com
Fri May 27 09:54:32 CDT 2016


> 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?

> 
> -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
> 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/e6e58b54/attachment.html>


More information about the swift-evolution mailing list