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]> 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]>: >> >> 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 >> ([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]> wrote: >>> >> >>> >> >>> >>> on Thu May 26 2016, Adrian Zubarev <[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] >>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>> > _______________________________________________ >>> > swift-evolution mailing list >>> > [email protected] >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>> > >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
