>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? -Thorsten > Am 27.05.2016 um 12:30 schrieb L. Mihalkovic <[email protected]>: > > 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 > <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>>: >>> >>> 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 >>> ([email protected] <mailto:[email protected]>) 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 >>>> >> <[email protected] <mailto:[email protected]>> wrote: >>>> >> >>>> >> >>>> >>> on Thu May 26 2016, Adrian Zubarev <[email protected] >>>> >>> <mailto:[email protected]>> 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 >>>> >> [email protected] <mailto:[email protected]> >>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> > _______________________________________________ >>>> > swift-evolution mailing list >>>> > [email protected] <mailto:[email protected]> >>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> > >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
