Here's a strawman idea. What if we go with '&' and 'where', but we enclose the whole thing in parentheses?
(class & Protocol1 & Protocol2 where .Foo == Int, .Bar : Baz) There are a couple of reasons I propose this syntax: - It makes it very clear where the definition of the type begins and ends. I understand people really despise angle brackets, but I really want some way to visually delineate the boundaries of the type. Plus, I imagine it makes syntax a little easier to parse and preemptively forbids some ambiguities. - It's a structural, not nominal, type, like a tuple, so it uses parens as well. This reserves "<" and ">" for generic types. - The '&' is easily understood - "Protocol1" *and* "Protocol2". It's also a signal that order doesn't matter - just like how order matters with things that use commas, like argument lists, tuples, and array members, order doesn't generally matter with bitwise or logical 'and' operators. - If we ever decide to have union types, we have a very elegant third form of nominal type syntax that naturally falls out: (MyClass1 | MyClass2 | MyClass3). Thoughts? Austin > On May 27, 2016, at 9:07 AM, Thorsten Seitz via swift-evolution > <[email protected]> wrote: > > >> Am 27.05.2016 um 16:54 schrieb Matthew Johnson <[email protected] >> <mailto:[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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
