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 <tseit...@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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
