> Am 27.05.2016 um 18:36 schrieb Austin Zheng <[email protected]>: > > I think the parentheses are the fundamental aspect of the suggestion :). > > Let me turn the question around. If tuples were declared like this: > > let myTuple : Int, String, Bool = (10, "hello", false) > > would the type be more or less readable? I find it a lot more difficult to > immediately parse than: > > let myTuple : (Int, String, Bool) = (10, "hello", false) > > At the same time, nobody's complained about tuple type parentheses getting in > the way.
Parentheses are the hallmark of tuples, so its natural to expect them around the tuple type as well :-) > > We're trying to establish a syntax that will hopefully be used for things > significantly more complicated than tuple definitions, which are just a list > of types. I think readability is a major concern. Typealiases should be > supported, but they shouldn't be required to make the feature useable. > > Finally, wouldn't we need some delimiter for nested existential definitions > anyways? Now you have the confusing situation where the outside definition > has no delimiters, but the inside ones do: Why is this confusing? The expression `2 * (3 + 1)` also has parentheses only around the part which needs them. Probably no one would require having to write `(2 * (3 + 1))` for consistency. > > // Why does the inner existential look fundamentally different than the outer > one? > // Not to mention, visually parsing the boundaries of this type when you look > at it in a function signature > let x : Protocol1, Protocol2, (Protocol 3 where .Foo == Int) where > Protocol2.Bar : Baz Using `&` instead of `,` will make it look better, too, IMHO: let x: Protocol1 & Protocol2 & (Protocol3 where .Foo == Int) where Protocol2.Bar: Baz or better (removing the asymmetry): let x: Protocol1 & (Protocol2 where .Bar : Baz) & (Protocol3 where .Foo == Int) or putting all constraints in the where clause for the whole expression: let x: Protocol1 & Protocol2 & Protocol3 where Protocol2.Bar: Baz, Protocol3.Foo == Int -Thorsten > > I hope that explains my reasoning. > > Best, > Austin > > >> On May 27, 2016, at 9:28 AM, Matthew Johnson <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> 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. >> >> >>> >>> 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
