[swift-evolution] [Fake-Proposal] Remove enums with associated objects

[Joe Groff]

> On Feb 20, 2017, at 10:34 PM, Tino Heth <2th at gmx.de> wrote:
> 
> Damn, there seems to be no better way to create reactions than saying something stupid ;-) - to bad the reactions tend to focus on the stupidity in this case...
> It should have been "union" instead of "sum", so basically having Optional<T> modeled as (T | Void)

This has been discussed several times in the past. If T is itself Optional<T>, then T | Void | Void == T | Void, meaning you can't safely use Optional to model potential failure in any generic situation that could itself produce Optional in normal circumstances. Having Optional<Optional<T>> not exist may seem superficially easy, but generates a bunch of downstream complexity, since you now need ad-hoc rules like "NSArrays can't contain nil". It's no coincidence that so many languages grow multiple null-like values in response to this situation—ObjC with NSNull; Javascript with null and undef; VB with Null, Nothing, Missing, and None; and so on. The parametric nature of sums makes it simpler to write correct generic code that works uniformly in all circumstances. I get the sense that in most cases, people are interested not in unions per se, since the proposed use cases often involve disjoint types anyway. Specific affordances like subtyping, cases-as-types, anonymous sum types, etc. could all potentially be added to the sum type model to make them easier to use, and I agree that they could potentially provide a better user experience than our current enum syntax, but I think the basic language model is the correct one.

-Joe