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

Fri May 27 09:52:25 CDT 2016

> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> From the point of view of the type system `P & Q` is an anonymous supertype of `P` and `Q`.
> This would be just the same if the syntax was `Any<P, Q>`. I don’t see a semantic difference here.
> 
> Whether that is a "container“ or not seems to be an implementation detail to me but should have nothing to do with the type system.
> In what way should it be "lossy“?
> 
> Am I missing something?

I was a bit confused as well and had to read this several times.  I think this is talking about a syntactic “container” - i.e. brackets of some kind (as opposed to a “free floating” syntax).  I don’t think it is talking about a semantic difference of any kind.  But maybe I am still confused an not understanding what was intended...

> 
> -Thorsten
> 
> 
>> Am 27.05.2016 um 12:30 schrieb L. Mihalkovic <laurent.mihalkovic at gmail.com <mailto:laurent.mihalkovic at gmail.com>>:
>> 
>> 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 <mailto: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 <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 <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 <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 <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/7a748190/attachment.html>