> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution > <swift-evolution@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.mihalko...@gmail.com >> <mailto:laurent.mihalko...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >> >>>>> >> >>>>> >>> on Thu May 26 2016, Adrian Zubarev <swift-evolution@swift.org >>>>> >>> <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> > _______________________________________________ >>>>> > swift-evolution mailing list >>>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> > >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
