[Pitch] merge types and protocols back together with type<Type, Protocol, ...>


(Thorsten Seitz) #1

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

-Thorsten

Anfang der weitergeleiteten E鈥慚ail:

路路路

Von: Adrian Zubarev <adrian.zubarev@devandartist.com>
Datum: 13. Mai 2016 um 16:50:52 MESZ
An: Thorsten Seitz <tseitz42@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鈥檇 like. :wink:

--
Adrian Zubarev
Sent with Airmail

Am 13. Mai 2016 bei 08:16:51, Thorsten Seitz (tseitz42@icloud.com) schrieb:

Am 12. Mai 2016 um 22:08 schrieb Adrian Zubarev via swift-evolution <swift-evolution@swift.org>:

I don鈥檛 get the part how `all<>` should allow `any<>`. Could you explain that a little bit in detail (I鈥檓 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@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@swift.org>:

protocol<SomeRealClass, SomeProtocol>
protocol<SomeRealStruct, SomeProtocol>

This feels really odd to me.

`type<SomeRealClass, SomeProtocol>` is more clear I鈥檇 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鈥檇 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@gmail.com) schrieb:

protocol<>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution