> On Feb 20, 2017, at 10:34 PM, Tino Heth <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
