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

[Slava Pestov]

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 at swift.org> wrote:
> 
> 
>> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution