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

[L. Mihalkovic]

It seem to me we are debating the how of a what that has not been defined. The root question behind all these alternatives seems to be to decide if the existential-ness should be carried by a 'container' that is then refined internally, or derived from the presence of the free-floating refinements. This is the question that splits the possible syntaxes into these 2 groups:

Any<> Any[]
Type<> Type<> 
Existential<>

and the (these are all straw man representations that should not limit the thinking)

P & Q
@P and @Q
is P , Q
P & Q typed

If the answer is to use a 'container' then the next question is to see its relationship to the other existing containers: is it the result of a transformation, is it a superset, or a super type; it is obviously lossy, but not entirely if the solution follows in some of Brent's past suggestion to make some existential types instantiate-able (which opens a very similar problem to what java faced for several years when trying to identify a universal collection literal syntax).
That will narrow down the field of possible matches... until one syntax emerges as conveying the meaning that is reflected by the answers to each question.

> On May 27, 2016, at 10:55 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> 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>:
>> 
>> Something like type<…> was considered at the very start of the whole discussion (in this thread), 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) 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> 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
>>> >
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> 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/6722d7fe/attachment.html>