Union instead of Optional


(frogcjn) #1

It’s kind of same idea of TypeScipt 2, at 46:21 in this video.

https://channel9.msdn.com/Events/Build/2016/B881

···

2016-2-16 GMT+8 14:36:28
Hi all,

I think the best way to solve the either problem is to separate it from generic.
Optional and Either shouldn’t work the same way of generic type.
It’s just a represent of multiple type in one location.

Using an old friend, Union in C.
union {
  case firstType
  case secondType
}

This is the final solution for the sub typing problem of optional.

A == union(A,A)
union(A,B) == union(B,A)
B == union(B,B)

B is subtype of union(A,B)
A is subtype of union(A,B)
union(A,B,C) is subtype of union(A,B,C,D,…)

suppose
a is subclass of A
b is subclass of B, then
  union(a,B) is subtype of union(A,B)
  union(A,b) is subtype of union(A,B)
  union(a,b) is subtype of union(a,B)
  union(a,b) is subtype of union(A,b)

union can have as many case as possible. e.g., union(A,B,C,D,…)

So the Optional<UITableView> should be union(UITableView, None)
and Optional<MyTableVIew> should be union(MyTableView, None), which is subclass of union(UITableView, None)

This is a final rational solution. I think.

-Jiannan


Sum-tuples
(Austin Zheng) #2

In addition, not everything in Swift can be modeled in terms of inheritance relationships.

I'm a little curious as to why union types keep on coming up, when enums can do everything they can and much more (methods, constraints on generic types, conformance to protocols).

Austin

···

On May 15, 2016, at 12:19 AM, David Hart via swift-evolution <swift-evolution@swift.org> wrote:

Enums with associated types in Swift are the equivalent of unions, even if they don’t have the name. I don’t see what your proposal is trying to solve?

On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It’s kind of same idea of TypeScipt 2, at 46:21 in this video.

https://channel9.msdn.com/Events/Build/2016/B881

<屏幕快照 2016-05-15 10.20.36.png>

2016-2-16 GMT+8 14:36:28
Hi all,

I think the best way to solve the either problem is to separate it from generic.
Optional and Either shouldn’t work the same way of generic type.
It’s just a represent of multiple type in one location.

Using an old friend, Union in C.
union {
  case firstType
  case secondType
}

This is the final solution for the sub typing problem of optional.

A == union(A,A)
union(A,B) == union(B,A)
B == union(B,B)

B is subtype of union(A,B)
A is subtype of union(A,B)
union(A,B,C) is subtype of union(A,B,C,D,…)

suppose
a is subclass of A
b is subclass of B, then
  union(a,B) is subtype of union(A,B)
  union(A,b) is subtype of union(A,B)
  union(a,b) is subtype of union(a,B)
  union(a,b) is subtype of union(A,b)

union can have as many case as possible. e.g., union(A,B,C,D,…)

So the Optional<UITableView> should be union(UITableView, None)
and Optional<MyTableVIew> should be union(MyTableView, None), which is subclass of union(UITableView, None)

This is a final rational solution. I think.

-Jiannan

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

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


(David Hart) #3

Enums with associated types in Swift are the equivalent of unions, even if they don’t have the name. I don’t see what your proposal is trying to solve?

···

On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

It’s kind of same idea of TypeScipt 2, at 46:21 in this video.

https://channel9.msdn.com/Events/Build/2016/B881

<屏幕快照 2016-05-15 10.20.36.png>

2016-2-16 GMT+8 14:36:28
Hi all,

I think the best way to solve the either problem is to separate it from generic.
Optional and Either shouldn’t work the same way of generic type.
It’s just a represent of multiple type in one location.

Using an old friend, Union in C.
union {
  case firstType
  case secondType
}

This is the final solution for the sub typing problem of optional.

A == union(A,A)
union(A,B) == union(B,A)
B == union(B,B)

B is subtype of union(A,B)
A is subtype of union(A,B)
union(A,B,C) is subtype of union(A,B,C,D,…)

suppose
a is subclass of A
b is subclass of B, then
  union(a,B) is subtype of union(A,B)
  union(A,b) is subtype of union(A,B)
  union(a,b) is subtype of union(a,B)
  union(a,b) is subtype of union(A,b)

union can have as many case as possible. e.g., union(A,B,C,D,…)

So the Optional<UITableView> should be union(UITableView, None)
and Optional<MyTableVIew> should be union(MyTableView, None), which is subclass of union(UITableView, None)

This is a final rational solution. I think.

-Jiannan

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


(Tino) #4

I don't know if there has been any internal discussion about using union-types instead of enums, but afaics, there are no obvious downsides for that approach.

I'm a little curious as to why union types keep on coming up, when enums can do everything they can and much more (methods, constraints on generic types, conformance to protocols).

Are there any strong reasons why those features would not be possible with union types?

There has been a discussion started because it is a little bit cumbersome to create enum-properties (and methods).
With unions, there would be no need for all those switch-statements, and would be possible to configure cases in a central location.
There has also been a proposal for "anonymous enums", which could be modeled with unions in a very elegant way.


(frogcjn) #5

Optional should be implement by union concept s instead of using generic.

Enum cannot be easily used to represent many types until you name all of them.

Both generic and enum solution cannot build a strong relation between optional type and its original type, for example, an Integer type has no reparation with Optional<Int>, until the compiler make a special case for Optional<T> to automatically unwrap or wrap for this.

···

在 2016年5月15日,15:19,David Hart <david@hartbit.com> 写道:

Enums with associated types in Swift are the equivalent of unions, even if they don’t have the name. I don’t see what your proposal is trying to solve?

On 15 May 2016, at 04:33, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

It’s kind of same idea of TypeScipt 2, at 46:21 in this video.

https://channel9.msdn.com/Events/Build/2016/B881

<屏幕快照 2016-05-15 10.20.36.png>

2016-2-16 GMT+8 14:36:28
Hi all,

I think the best way to solve the either problem is to separate it from generic.
Optional and Either shouldn’t work the same way of generic type.
It’s just a represent of multiple type in one location.

Using an old friend, Union in C.
union {
  case firstType
  case secondType
}

This is the final solution for the sub typing problem of optional.

A == union(A,A)
union(A,B) == union(B,A)
B == union(B,B)

B is subtype of union(A,B)
A is subtype of union(A,B)
union(A,B,C) is subtype of union(A,B,C,D,…)

suppose
a is subclass of A
b is subclass of B, then
  union(a,B) is subtype of union(A,B)
  union(A,b) is subtype of union(A,B)
  union(a,b) is subtype of union(a,B)
  union(a,b) is subtype of union(A,b)

union can have as many case as possible. e.g., union(A,B,C,D,…)

So the Optional<UITableView> should be union(UITableView, None)
and Optional<MyTableVIew> should be union(MyTableView, None), which is subclass of union(UITableView, None)

This is a final rational solution. I think.

-Jiannan

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


(Joe Groff) #6

Unlike sum types, such as Swift enums, unions don't have parametricity, because (T \union Nil) \union Nil == T \union Nil. This means that things like collections containing Optionals don't just work, since it becomes impossible for operations like 'find' to distinguish 'nil' as a value in the container from 'nil' as a "not found" result. Languages without sum types tend to compensate by growing multiple "nil"-like values—ObjC has NSNull, Javascript has undefined and null, VB has Null, Nothing, *and* None, and so on.

-Joe

···

On May 14, 2016, at 7:33 PM, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

It’s kind of same idea of TypeScipt 2, at 46:21 in this video.

https://channel9.msdn.com/Events/Build/2016/B881

<屏幕快照 2016-05-15 10.20.36.png>

2016-2-16 GMT+8 14:36:28
Hi all,

I think the best way to solve the either problem is to separate it from generic.
Optional and Either shouldn’t work the same way of generic type.
It’s just a represent of multiple type in one location.

Using an old friend, Union in C.
union {
  case firstType
  case secondType
}

This is the final solution for the sub typing problem of optional.

A == union(A,A)
union(A,B) == union(B,A)
B == union(B,B)

B is subtype of union(A,B)
A is subtype of union(A,B)
union(A,B,C) is subtype of union(A,B,C,D,…)

suppose
a is subclass of A
b is subclass of B, then
  union(a,B) is subtype of union(A,B)
  union(A,b) is subtype of union(A,B)
  union(a,b) is subtype of union(a,B)
  union(a,b) is subtype of union(A,b)

union can have as many case as possible. e.g., union(A,B,C,D,…)

So the Optional<UITableView> should be union(UITableView, None)
and Optional<MyTableVIew> should be union(MyTableView, None), which is subclass of union(UITableView, None)

This is a final rational solution. I think.

-Jiannan

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


(Leonardo Pessoa) #7

Optional a could be implemented with both enumerated and unions with this
proposal but there should be an Undefined type whose only possible value is
nil. It would make no sense but you could declare a function argument or
return or even a property whose type is Undefined too. And this would lead
to otherwise unnecessary code.

I do agree with the idea of unions but I don't believe optionals would be
better implemented with it,

···

On Saturday, 14 May 2016, Cao Jiannan via swift-evolution < swift-evolution@swift.org> wrote:

It’s kind of same idea of TypeScipt 2, at 46:21 in this video.

https://channel9.msdn.com/Events/Build/2016/B881

2016-2-16 GMT+8 14:36:28

Hi all,

I think the best way to solve the either problem is to separate it from
generic.
Optional and Either shouldn’t work the same way of generic type.
It’s just a represent of multiple type in one location.

Using an old friend, Union in C.
union {
case firstType
case secondType
}

This is the final solution for the sub typing problem of optional.

A == union(A,A)
union(A,B) == union(B,A)
B == union(B,B)

B is subtype of union(A,B)
A is subtype of union(A,B)

union(A,B,C) is subtype of union(A,B,C,D,…)

suppose
a is subclass of A
b is subclass of B, then
union(a,B) is subtype of union(A,B)
union(A,b) is subtype of union(A,B)
union(a,b) is subtype of union(a,B)
union(a,b) is subtype of union(A,b)

union can have as many case as possible. e.g., union(A,B,C,D,…)

So the Optional<UITableView> should be union(UITableView, None)
and Optional<MyTableVIew> should be union(MyTableView, None), which is
subclass of union(UITableView, None)

This is a final rational solution. I think.

-Jiannan

--
- Leonardo


(Thorsten Seitz) #8

Yes, enums are like explicit named type unions whereas ad hoc type unions can be useful exactly because they are ad hoc.
It is kind of like named functions vs. anonymous functions. Both have their place.

Ceylon makes tremendous use of union and intersection types. While they don’t have enums in the Swift sense they have something very similar, so they certainly make use of both approaches, too. Like I said both have their place and introducing type unions shouldn’t replace enums (unless we should discover that type unions can do all that enums do, e.g. with extensions it might even be possible to add methods to type unions in Swift).

-Thorsten

···

Am 15.05.2016 um 13:07 schrieb Tino Heth via swift-evolution <swift-evolution@swift.org>:

I don't know if there has been any internal discussion about using union-types instead of enums, but afaics, there are no obvious downsides for that approach.

I'm a little curious as to why union types keep on coming up, when enums can do everything they can and much more (methods, constraints on generic types, conformance to protocols).

Are there any strong reasons why those features would not be possible with union types?

There has been a discussion started because it is a little bit cumbersome to create enum-properties (and methods).
With unions, there would be no need for all those switch-statements, and would be possible to configure cases in a central location.
There has also been a proposal for "anonymous enums", which could be modeled with unions in a very elegant way.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Austin Zheng) #9

Precisely. To me unions are to enums with associated type the same way tuples are to structs. One is named, has well-defined semantics, can conform to protocols, can have complex internal structure, can have methods, etc. The other is ad-hoc and lightweight, easy to define at the site of use, best suited for simple purposes, has special syntax to support it.

Even if we can extend tuples in the future, though, I wouldn't want structs to go away. When exceeding some level of complexity structs are just more explicit than tuples, and therefore easier to understand.

Finally, please note that Ceylon is a pervasively object-oriented language with a single root superclass. Neither of those is true for Swift, which chooses to solve a lot of problems in a different (and I would argue, superior) way. So solutions that might work well in Ceylon might not be suited for Swift, at least not without modification, and vice versa. The core team could certainly have chosen to model Swift's type system after that of e.g. Scala, but they chose not to, and I think they did so for good reason.

Austin

···

On May 16, 2016, at 2:58 AM, Thorsten Seitz <tseitz42@icloud.com> wrote:

Yes, enums are like explicit named type unions whereas ad hoc type unions can be useful exactly because they are ad hoc.
It is kind of like named functions vs. anonymous functions. Both have their place.

Ceylon makes tremendous use of union and intersection types. While they don’t have enums in the Swift sense they have something very similar, so they certainly make use of both approaches, too. Like I said both have their place and introducing type unions shouldn’t replace enums (unless we should discover that type unions can do all that enums do, e.g. with extensions it might even be possible to add methods to type unions in Swift).

-Thorsten

Am 15.05.2016 um 13:07 schrieb Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

I don't know if there has been any internal discussion about using union-types instead of enums, but afaics, there are no obvious downsides for that approach.

I'm a little curious as to why union types keep on coming up, when enums can do everything they can and much more (methods, constraints on generic types, conformance to protocols).

Are there any strong reasons why those features would not be possible with union types?

There has been a discussion started because it is a little bit cumbersome to create enum-properties (and methods).
With unions, there would be no need for all those switch-statements, and would be possible to configure cases in a central location.
There has also been a proposal for "anonymous enums", which could be modeled with unions in a very elegant way.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #10

Precisely. To me unions are to enums with associated type the same way tuples are to structs.

Me too — and I think it would be beautiful if it could be modeled that way, so that there is always a pair of a named and an anonymous variant for functions (closures), types (structs) and enums (yet to come).

One is named, has well-defined semantics, can conform to protocols, can have complex internal structure, can have methods, etc. The other is ad-hoc and lightweight, easy to define at the site of use, best suited for simple purposes, has special syntax to support it.

That also true for closures, yet I'm very happy how flexible regular methods can be used as blocks.

Even if we can extend tuples in the future, though, I wouldn't want structs to go away. When exceeding some level of complexity structs are just more explicit than tuples, and therefore easier to understand.

I don't think something as fundamental as structs should ever be removed, but imho it would be great to see some unification of concepts…

struct Point: Tuple<x: Float, y: Float> {
  // methods...
  // "inheritance for structs"-poposal delayed until Swift 4 :wink:
}


(Michael Peternell) #11

Swift has a root class, it is called SwiftObject and it's visible from Objective-C :wink: Just thinking about it.. it makes sense: the whole reference-counting-stuff has to live somewhere in the object, and there has to be some kind of isa-pointer to allow for subclassing (and Objective-C interoperability). So there is some common behavior regarding all classes defined from Swift (they all implement retain, release, autorelease, isEqual:, class, respondsToSelector:, the whole NSObject-protocol...) => what I want to express: Java has a root-class, C++ has no root class - that's uncontested; but Swift is somewhere in-between IMHO.

And for enums and unions.. I think they are different. enums are "sum-types" and unions are... well... "union-types", when you think of data types as sets. E.g. if A, B are data types (sets), then an enum that can be either anA(A) or aB(B) can be thought of as the set A+B (and if A \intersect B \not\eq \emptyset, you can think of this as (0,A)\union (1,B) ). A union B is not the same. In C, the unions are not even safe, because they are not discriminated in any way. In Swift they make an isomorphic set if A and B are disjoint. If A=String and B=Int, A `enum` B is isomorphic to A `union` B (sorry for abusing Haskell syntax :-/ ). But if A=Iterable<String> and B=Array<String>, they are not the same, because now A is a superset of B. So A `enum` B is a strict superset of A `union` B (== A). I can already imagine weird bugs coming to the surface from this distinction, all of which can be solved by disallowing union types altogether.

Therefore I think that unions are not worth the trouble at all. And they are even possible right now: Instead of writing

    union MyUnion { Int, String }
    // or typealias MyUnion = (Int | String) // ?

you'd have to write

    protocol MyUnion {}
    extension Int: MyUnion {}
    extension String: MyUnion {}

The two definitions are basically equivalent, and the second is already valid Swift.

I have used unions a few times in C though, e.g. for converting from void* to int or stuff like that, at a time when I didn't know about reinterpret_cast (Swift: unsafeBitcast) yet. The few occasions where they are use in the C standard library, they are always discriminated, like a union between a struct(int type, float foo, ...) and another struct(int type, char bar[20], ...) where the type parameter is in both values and can be used to distinguish them. In Swift they are always distinguishable because of runtime type information (except for the case described above), so you can as well just use an enum and make that information obvious. To unpack the information you can use `if let` when dealing with a union, and you can use `if case` or `switch` when dealing with an enum. I don't see how unions would be more convenient to be worth the trouble. Swift unions would be like (C unions + RTTI (runtime type information)), with RTTI replacing the discriminator element of enums, except when the types overlap. So I doubt that anyone will find a decent (realistic!) use-case that is not just as easily (and conveniently) implemented using enums. I think I just proved that there is no such use case :wink: The best way to convince me otherwise would be to provide a realistic piece of example code.

Regards,
Michael

···

Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution <swift-evolution@swift.org>:

Precisely. To me unions are to enums with associated type the same way tuples are to structs. One is named, has well-defined semantics, can conform to protocols, can have complex internal structure, can have methods, etc. The other is ad-hoc and lightweight, easy to define at the site of use, best suited for simple purposes, has special syntax to support it.

Even if we can extend tuples in the future, though, I wouldn't want structs to go away. When exceeding some level of complexity structs are just more explicit than tuples, and therefore easier to understand.

Finally, please note that Ceylon is a pervasively object-oriented language with a single root superclass. Neither of those is true for Swift, which chooses to solve a lot of problems in a different (and I would argue, superior) way. So solutions that might work well in Ceylon might not be suited for Swift, at least not without modification, and vice versa. The core team could certainly have chosen to model Swift's type system after that of e.g. Scala, but they chose not to, and I think they did so for good reason.


(Thorsten Seitz) #12

Precisely. To me unions are to enums with associated type the same way tuples are to structs. One is named, has well-defined semantics, can conform to protocols, can have complex internal structure, can have methods, etc. The other is ad-hoc and lightweight, easy to define at the site of use, best suited for simple purposes, has special syntax to support it.

Even if we can extend tuples in the future, though, I wouldn't want structs to go away. When exceeding some level of complexity structs are just more explicit than tuples, and therefore easier to understand.

Finally, please note that Ceylon is a pervasively object-oriented language with a single root superclass. Neither of those is true for Swift, which chooses to solve a lot of problems in a different (and I would argue, superior) way. So solutions that might work well in Ceylon might not be suited for Swift, at least not without modification, and vice versa. The core team could certainly have chosen to model Swift's type system after that of e.g. Scala, but they chose not to, and I think they did so for good reason.

Swift has a root class, it is called SwiftObject and it's visible from Objective-C :wink: Just thinking about it.. it makes sense: the whole reference-counting-stuff has to live somewhere in the object, and there has to be some kind of isa-pointer to allow for subclassing (and Objective-C interoperability). So there is some common behavior regarding all classes defined from Swift (they all implement retain, release, autorelease, isEqual:, class, respondsToSelector:, the whole NSObject-protocol...) => what I want to express: Java has a root-class, C++ has no root class - that's uncontested; but Swift is somewhere in-between IMHO.

And for enums and unions.. I think they are different. enums are "sum-types" and unions are... well... "union-types", when you think of data types as sets. E.g. if A, B are data types (sets), then an enum that can be either anA(A) or aB(B) can be thought of as the set A+B (and if A \intersect B \not\eq \emptyset, you can think of this as (0,A)\union (1,B) ). A union B is not the same. In C, the unions are not even safe, because they are not discriminated in any way. In Swift they make an isomorphic set if A and B are disjoint. If A=String and B=Int, A `enum` B is isomorphic to A `union` B (sorry for abusing Haskell syntax :-/ ). But if A=Iterable<String> and B=Array<String>, they are not the same, because now A is a superset of B. So A `enum` B is a strict superset of A `union` B (== A). I can already imagine weird bugs coming to the surface from this distinction, all of which can be solved by disallowing union types altogether.

Ceylon’s type system handles these things nicely. Iterable<String> | Array<String> would reduce to Iterable<String>, for example, and when switching over union types the type checker knows when types are not disjoint (disallowing the switch) or whether the switch is exhaustive.

For more details, see http://ceylon-lang.org/documentation/1.2/tour/types/

Therefore I think that unions are not worth the trouble at all. And they are even possible right now: Instead of writing

   union MyUnion { Int, String }
   // or typealias MyUnion = (Int | String) // ?

you'd have to write

   protocol MyUnion {}
   extension Int: MyUnion {}
   extension String: MyUnion {}

The two definitions are basically equivalent, and the second is already valid Swift.

Alas, that is only possible for explicit named unions but the power of type unions lies in their „ad hoc“-ness, e.g. in generic unions like

func union<T, U>(a: Set<T>, b: Set<U>) -> Set<T | U> { … } // Note: all examples in hypothetically extended Swift syntax instead of Ceylon syntax

extension Dictionary {
  func getOrDefault<Default>(default: Default) -> Value | Default // in the general simple case Default == Value, which results in Value | Default == Value
}

Ceylon models the concept of empty and non-empty streams by defining

protocol Iterable {
  associatedtype Element
  associatedtype Absent : Null = Null // Null is the type containing a single value null (= nil in Swift); Ceylon’s optionals are just type unions T? == T | Null
  
  var first: Absent | Element { get }
  var rest: Iterable where Iterable.Element == Element, Iterable.Absent == Null

  // Produces a non-empty stream with a given initial element, followed by the elements of this stream, in the order in which they occur in this stream.
  func follow(head: Other) -> Iterable where Iterable.Element == Element | Other, Iterable.Absent = Nothing
  …
}

This means that
  Iterable // with the default Absent = Null
can be empty, whereas
  Iterable where Absent == Nothing
cannot be empty because Nothing is the bottom type (the intersection of all types) with no elements, i.e. the union Nothing | Element == Element and therefore `first` always answers an element!

An example for intersection types in Ceylon (which requires that optionals are modeled as type union T | Null where Null is not a subtype of Any):

protocol Collection {
  func coalesced() -> [Value & Any] // answer an array containing all non nil elements
}

Just some examples demonstrating a bit of the beauty of type unions and type intersections if baked into the language and embraced by the standard library.

-Thorsten

···

Am 16.05.2016 um 17:29 schrieb Michael Peternell via swift-evolution <swift-evolution@swift.org>:

Am 16.05.2016 um 12:07 schrieb Austin Zheng via swift-evolution <swift-evolution@swift.org>:

I have used unions a few times in C though, e.g. for converting from void* to int or stuff like that, at a time when I didn't know about reinterpret_cast (Swift: unsafeBitcast) yet. The few occasions where they are use in the C standard library, they are always discriminated, like a union between a struct(int type, float foo, ...) and another struct(int type, char bar[20], ...) where the type parameter is in both values and can be used to distinguish them. In Swift they are always distinguishable because of runtime type information (except for the case described above), so you can as well just use an enum and make that information obvious. To unpack the information you can use `if let` when dealing with a union, and you can use `if case` or `switch` when dealing with an enum. I don't see how unions would be more convenient to be worth the trouble. Swift unions would be like (C unions + RTTI (runtime type information)), with RTTI replacing the discriminator element of enums, except when the types overlap. So I doubt that anyone will find a decent (realistic!) use-case that is not just as easily (and conveniently) implemented using enums. I think I just proved that there is no such use case :wink: The best way to convince me otherwise would be to provide a realistic piece of example code.

Regards,
Michael

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