[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Austin Zheng austinzheng at gmail.com
Fri May 27 11:18:55 CDT 2016 

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 <swift-evolution at swift.org> wrote:
> 
> 
>> Am 27.05.2016 um 16:54 schrieb Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>>:
>> 
>>> 
>>> On May 27, 2016, at 8:18 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 <svabox at gmail.com <mailto:svabox at 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 at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>> wrote:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>> on Thu May 26 2016, Adrian Zubarev <swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> > _______________________________________________
>>>>>>> > swift-evolution mailing list
>>>>>>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/b8f959f2/attachment.html>

More information about the swift-evolution mailing list