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

[Vladimir.S]

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
>