> Am 27.05.2016 um 18:28 schrieb Matthew Johnson <[email protected]>: > > > > Sent from my iPad > > On May 27, 2016, at 11:18 AM, Austin Zheng <[email protected] > <mailto:[email protected]>> wrote: > >> 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? > > Generally in favor. But I would not require the parentheses. I believe they > would be allowed optionally automatically, just as (Int) is the same as Int > (because single element tuples don't exist and the underlying type is used > directly instead). It seems better to leave parentheses up to a matter of > style.
Totally agree. Parentheses should only be required to resolve ambiguities. -Thorsten > > >> >> Austin >> >> >>> On May 27, 2016, at 9:07 AM, Thorsten Seitz via swift-evolution >>> <[email protected] <mailto:[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] <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
