[swift-evolution] Fwd: [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz]

Resending message to list. Seems like iOS Mail (or me) really has problems with setting the reply to the list automatically :-(
Thanks, Adrian, for notifying me.

-Thorsten 

Anfang der weitergeleiteten E‑Mail:

> Von: Adrian Zubarev <adrian.zubarev at devandartist.com>
> Datum: 13. Mai 2016 um 16:50:52 MESZ
> An: Thorsten Seitz <tseitz42 at icloud.com>
> Betreff: Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>
> 
> Your message was private, maybe by accident? Consider to resend it to the public thread if you’d like. ;)
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Mai 2016 bei 08:16:51, Thorsten Seitz (tseitz42 at icloud.com) schrieb:
> 
>> 
>> 
>> Am 12. Mai 2016 um 22:08 schrieb Adrian Zubarev via swift-evolution <swift-evolution at swift.org>:
>> 
>>> I don’t get the part how `all<>` should allow `any<>`. Could you explain that a little bit in detail (I’m not familiar with Ceylon)?
>> 
>> 
>> `all<>` and `any<>` form a pair of complementary type operators, one creating the intersection of the given types (your proposal) and the other creating the union of the given types. As Ceylon has demonstrated that both are really useful I'd like to have both in Swift and therefore would prefer that both should be named such that this duality is visible. Having `type<>` and `any<>` would certainly be possible technically but the naming would not be good.
>> 
>>> 
>>> From my point of view `any<>` is something different that I pitched here. `any<>` could be proposed in its own thread, because it is way different than `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
>> 
>> 
>> You are right, `any<>` is something different and could be proposed in its own thread. I just wanted to extend the context for finding a good name for `type<>`.
>> 
>>> 
>>> Here is a little example where `any<>` gets strange:
>>> 
>>> func foo(value: any<String, Int>) -> any<String, Int> {
>>> 
>>>     // how would one use value here?
>>>     // what about its properties
>>>     // what will foo return and how to use the result
>>> }
>> 
>> 
>> Ceylon uses flow typing for that (if (is String value) { /* value has type String here */ }).
>> In Swift the equivalent would be `if let string = value as? String { ... }`:
>> 
>> func foo(value: any<Strint, Int>) -> any<String, Int> {
>>    if let string = value as? String {
>>       return string.characters.count
>>    }
>>    else if let int= value as? Int {
>>       return String(int)
>>    }
>> }
>> 
>> A more sensical example using a type union would be the union of two sets:
>> 
>> func union<T, U>(a: Set<T>, b: Set<U>) -> Set<any<T, U>> { ... }
>> 
>> And for type intersection the intersection of two sets:
>> 
>> func intersection<T, U>(a: Set<T>, b: Set<U>) -> Set<all<T, U>> { ... }
>> 
>> (Ceylon's type operators just read better there...)
>> 
>> Another example for type unions:
>> Ceylon like Swift makes heavy use of optionals but where Swift has a generic wrapper Optional<T> Ceylon just makes use of type unions: in Ceylon T? is syntactic sugar for the type union T | Null where Null is the type having the singleton value null.
>> 
>> FWIW Microsoft's Typescript gained union and intersection types about (I think) a year ago.
>> 
>>> 
>>> One benefit of `any<>` is the replacement of overloading, at least for the type part of the function.
>> 
>> 
>> Exactly.
>> 
>>  
>>> `all<>` could be seen as an alternative name for `type<>`, but to me its not clear what `all<>` can do, whereas `type<>` is almost like `protocol<>`.
>> 
>> 
>> Right, `all<>` is just an alternative name for `type<>`. There is no change in functionality.
>> 
>> -Thorsten
>> 
>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseitz42 at icloud.com) schrieb:
>>> 
>>>> 
>>>> Ceylon uses „&" for intersection types, i.e.
>>>> 
>>>> SomeRealClass & SomeProtocol
>>>> 
>>>> and the bar („|“) for union types, i.e. 
>>>> 
>>>> String | Int
>>>> 
>>>> That has proven to be very lightweight and readable in Ceylon where it is heavily used to good effect.
>>>> 
>>>> 
>>>> I agree with you that
>>>> 
>>>> type<SomeRealClass, SomeProtocol> 
>>>> 
>>>> is much nicer than protocol<> for intersection types but to keep the door open for union types, I would prefer
>>>> 
>>>> all<SomeRealClass, SomeProtocol>
>>>> 
>>>> This would allow
>>>> 
>>>> any<String, Int>
>>>> 
>>>> to be used for union types.
>>>> 
>>>> -Thorsten
>>>> 
>>>> 
>>>>> Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution <swift-evolution at swift.org>:
>>>>> 
>>>>> protocol<SomeRealClass, SomeProtocol> 
>>>>> protocol<SomeRealStruct, SomeProtocol> 
>>>>> 
>>>>> This feels really odd to me. 
>>>>> 
>>>>> `type<SomeRealClass, SomeProtocol>` is more clear I’d say.
>>>>> 
>>>>> I think this would be a good addition to the type system and allow us to build more complex and type save code.
>>>>> 
>>>>> But still I’d love to discuss if there might be any disadvantages to this feature.
>>>>> 
>>>>> -- 
>>>>> Adrian Zubarev
>>>>> Sent with Airmail
>>>>> 
>>>>> Am 12. Mai 2016 bei 15:11:00, Vladimir.S (svabox at gmail.com) schrieb:
>>>>> 
>>>>>> protocol<> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/edd5af4b/attachment.html>