> On May 28, 2016, at 10:26 AM, Thorsten Seitz <tseit...@icloud.com> wrote: > > Austin raised the point (or reminded of Joe’s raising the point) of possible > problems when returning constrained existentials from generic functions: > > func foo<P, Q>(p: P, q: Q) -> any<Collection where .Element == P> where P: > Equatable { … } > > would require parentheses when using `&` instead of any<> > > func foo<P, Q>(p: P, q: Q) -> (Collection where .Element == P) where P: > Equatable { … } > > This would even be the case if there was no constraint on P: > > func foo<P, Q>(p: P, q: Q) -> (Collection where .Element == P) { … } > > > An alternative would be to use `with` for existentials instead of `where`: > > func foo<P, Q>(p: P, q: Q) -> Collection with .Element == P where P: > Equatable { … } > > But even then this would be more readable either with parentheses (now just > as a matter of style) or a line break: > > func foo<P, Q>(p: P, q: Q) -> Collection with .Element == P > where P: Equatable { … } > > -Thorsten
We could make parentheses optional in the general case, and just have them mandatory in the following situations: - You want to nest an existential literal inside another existential literal: let a : Protocol1, (Protocol2 where .Blah == Int), Protocol3 = foo() - You want to return an existential with more than one term and/or a where clause from a function that has a generic where clause func foo<P, Q>(p: P, q: Q) -> (Collection with .Element == P) where P : Equatable { ... } - You want to use an existential as a function argument, and that existential has more than one term and/or a where clause func foo(x: Protocol1, y: (Protocol2 where .Blah == Int), z: Protocol3) { ... } Would that be a reasonable compromise? > > >> >> -Matthew >> >>> >>> typealias P3Int = Protocol 3 where .Foo == Int >>> let x : Protocol1, Protocol2, P3Int where Protocol2.Bar : Baz >>> >>> If you are writing the entire type in a single location I expect the >>> conventional style to be like this: >>> >>> let x : Protocol1, Protocol2, Protocol 3 where Protocol2.Bar : Baz, >>> Protocol3.Foo == Int >>> >>> With all associated types constraints in a single `where` clause as we >>> other places they are written in Swift. >>> >>> Maybe I am wrong about that and a different conventional style would emerge >>> (for example, where clauses clustered with the related protocol). >>> >>> But *requiring* parentheses is really orthogonal to the style issue of >>> where and when it is considered *advisable* to use them. >>> >>> -Matthew >>> >>>> >>>> I hope that explains my reasoning. >>>> >>>> Best, >>>> Austin >>>> >>>> >>>>> On May 27, 2016, at 9:28 AM, Matthew Johnson <matt...@anandabits.com >>>>> <mailto:matt...@anandabits.com>> wrote: >>>>> >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>> On May 27, 2016, at 11:18 AM, Austin Zheng <austinzh...@gmail.com >>>>> <mailto:austinzh...@gmail.com>> 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 >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>> >>>>>>> >>>>>>>> Am 27.05.2016 um 16:54 schrieb Matthew Johnson <matt...@anandabits.com >>>>>>>> <mailto:matt...@anandabits.com>>: >>>>>>>> >>>>>>>>> >>>>>>>>> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution >>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <sva...@gmail.com >>>>>>>>>> <mailto:sva...@gmail.com>>: >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>>> <mailto:swift-evolution@swift.org >>>>>>>>>>>> <mailto:swift-evolution@swift.org>>>: >>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> (swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>>> <mailto:swift-evolution@swift.org >>>>>>>>>>>> <mailto:swift-evolution@swift.org>>) 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 >>>>>>>>>>>>> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>>>> >> <mailto:swift-evolution@swift.org >>>>>>>>>>>>> >> <mailto:swift-evolution@swift.org>>> wrote: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> on Thu May 26 2016, Adrian Zubarev <swift-evolution@swift.org >>>>>>>>>>>>> >>> <mailto:swift-evolution@swift.org> >>>>>>>>>>>>> >>> <mailto:swift-evolution@swift.org >>>>>>>>>>>>> >>> <mailto:swift-evolution@swift.org>>> 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 >>>>>>>>>>>>> >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>>>> >> <mailto:swift-evolution@swift.org >>>>>>>>>>>>> >> <mailto:swift-evolution@swift.org>> >>>>>>>>>>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>>>>>>>> > _______________________________________________ >>>>>>>>>>>>> > swift-evolution mailing list >>>>>>>>>>>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>>>> > <mailto:swift-evolution@swift.org >>>>>>>>>>>>> > <mailto:swift-evolution@swift.org>> >>>>>>>>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>>>>>>>> > >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> swift-evolution mailing list >>>>>>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>>>> <mailto:swift-evolution@swift.org >>>>>>>>>>>>> <mailto:swift-evolution@swift.org>> >>>>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> swift-evolution mailing list >>>>>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>>> <mailto:swift-evolution@swift.org >>>>>>>>>>>> <mailto:swift-evolution@swift.org>> >>>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> swift-evolution mailing list >>>>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>>>> _______________________________________________ >>>>>>>>> swift-evolution mailing list >>>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution