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

Fri May 27 12:46:22 CDT 2016

For me requiring parentheses for this 'feature' will confuse in most cases 
as looks similar to tuple definition:

let x : (Int, String, Bool) = oneThing
let y : (MyProto & Hashable) = anotherThing

but below looks IMO more clean and I instantly(don't need to parse first 
open parenthesis) see that this is a 'conjunction' of protocols not tuple :

let y : MyProto & Hashable = anotherThing

Bur +1 for optional parentheses

On 27.05.2016 19:36, Austin Zheng via swift-evolution wrote:
> 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.
>
> 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 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
>
> I hope that explains my reasoning.
>
> Best,
> Austin
>
>
>> On May 27, 2016, at 9:28 AM, Matthew Johnson <matthew at anandabits.com
>> <mailto:matthew at anandabits.com>> wrote:
>>
>>
>>
>> Sent from my iPad
>>
>> On May 27, 2016, at 11:18 AM, Austin Zheng <austinzheng at gmail.com
>> <mailto:austinzheng at 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 at swift.org <mailto: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>>:
>>>>>>>>>
>>>>>>>>> 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>),
>>>>>>>>> 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>)
>>>>>>>>> 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>>
>>>>>>>>>> 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>>
>>>>>>>>>> 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>
>>>>>>>>>> >> 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>
>>>>>>>>>> > 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>
>>>>>>>>>> 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>
>>>>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> 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
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>