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

Vladimir.S svabox at gmail.com
Thu May 26 12:47:44 CDT 2016


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> wrote:
>>
>>
>>> on Thu May 26 2016, Adrian Zubarev <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
>> 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
>


More information about the swift-evolution mailing list