> On May 28, 2016, at 10:26 AM, Thorsten Seitz <[email protected]> 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 <[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
