> On May 27, 2016, at 4:52 PM, Matthew Johnson <[email protected]> wrote: > >> >> On May 27, 2016, at 7:20 AM, Thorsten Seitz via swift-evolution >> <[email protected] <mailto:[email protected]>> 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“? what is by definition lossy, is the relationship between a type and an existential type that can represent it. Comes from the fact that there is no way to go back to the type we started from once all we hold is the existential (i.e. means it is a one —> n mapping relationship, not a 1 —> 1). Not the notation. right? >> >> 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... given the semantic we wish to express (combination of conformance declarations), what possible ways do we have to express it. It come down to 2 families of syntax: the ‘container’ form, of which I gave a few examples, versus the non-container form (or free-floating conformance list) of which the straight list is the most obvious, but not the only one. Joe Groff was reminding us that the second group of syntax also exists. Compilers love Any<P...Q> , people’s brains love P & Q > >> >> -Thorsten >> >> >>> Am 27.05.2016 um 12:30 schrieb L. Mihalkovic <[email protected] >>> <mailto:[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<> this was meant to read Type<…> 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] <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
