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

[Tino Heth]

Thanks for the thorough explanation - hope it will spawn some enum-proposals in the future ;-)

> 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.
In general, I'd consider this to be an advantage of union types:
Using try? with a function that may throw as well as return nil feels quite complicated to me, because I just would use "try" if I cared about wether an error happened or not. 
Luckily, I never encountered more than two levels of optionality, and I guess this won't happen often in real-world code.

> 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".
I never questioned the rules of NSArray and NSNull... is this actually because id is like object | nil? (more or less rhetorical question - to tired to think it through :)

> 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.
Does VB really have union types?
The only language I know which modeled optionals as (Type | Null) is Ceylon, which seems to have a favor for union types - but have no idea if its designers are happy with that decision.