One example is that in Java, it is difficult to distinguish a failed hashtable lookup from a hashtable lookup that produced a value of null. In Swift, these would be modeled as .none and .some(.none), respectively.
Slava > On Feb 21, 2017, at 8:36 AM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Feb 20, 2017, at 10:34 PM, Tino Heth <2...@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 > _______________________________________________ > swift-evolution mailing list > 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
