> Am 27.05.2016 um 16:54 schrieb Matthew Johnson <[email protected]>: > >> >> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Personally I think `&` is more lightweight (and it is established in other >> languages like Ceylon and Typescript) and `where` is more expressive (and >> established in Swift for introducing constraints), so I would stay with >> these. > > I agree. If we can make `&` with `where` work syntactically it would be nice > to go in this lighter weight direction. If we decide to do that the question > then becomes what to do with `protocol`. Would it be feasible to replace it > with `&` in Swift 3 if we decide on that direction?
Yep. `protocol` should be replaced with `&` in that case. -Thorsten > >> >> -Thorsten >> >> >>> Am 27.05.2016 um 14:34 schrieb Vladimir.S <[email protected] >>> <mailto:[email protected]>>: >>> >>> Btw, in case we have `where` keyword in syntax related to types/protocols >>> (when defining constrains. and not some symbol like '>>'.. don't know, for >>> example), why we can't have 'and' keyword also when discuss the syntax of >>> type/protocol conjunction? >>> I.e. >>> >>> let x: P and Q >>> let x: P and Q where P.T == Q.T >>> let x: P and Q and R >>> >>> or, for consistency, as I understand it, we should have >>> let x: P & Q >> P.T == Q.T >>> >>> On 27.05.2016 11:55, Thorsten Seitz via swift-evolution 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]> >>>>> <mailto:[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 >>>>> >>>>> <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]> >>>>> <mailto:[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]> >>>>>> >> <mailto:[email protected] >>>>>> >> <mailto:[email protected]>>> wrote: >>>>>> >> >>>>>> >> >>>>>> >>> on Thu May 26 2016, Adrian Zubarev <[email protected] >>>>>> >>> <mailto:[email protected]> <mailto:[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]> >>>>>> >> <mailto:[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]> >>>>>> > <mailto:[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]> >>>>>> <mailto:[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]> >>>>> <mailto:[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
