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. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
