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, then T | Void | Void == T | Void, meaning you can't safely use
> Optional to model potential failure in any generic
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
>
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
modeled as (T | Void)
> Enums in Swift *are* sum types.
> On Feb 20, 2017, at 12:07 PM, Tino Heth via swift-evolution
> wrote:
>
> Obviously, this won't become an accepted proposal - neither the time nor the
> author would be appropriate for such a result.
> But the list seems a little bit bored lately, so maybe a
A lot of problems look algebra-like. Best to have sums and products at your
disposal.
Cheekily,
~Robert Widmann
2017/02/20 15:07、Tino Heth via swift-evolution
のメッセージ:
> Obviously, this won't become an accepted proposal - neither the time nor the
> author would
Obviously, this won't become an accepted proposal - neither the time nor the
author would be appropriate for such a result.
But the list seems a little bit bored lately, so maybe a relaxed discussion
without practical implications isn't the worst thing to have now ;-)
Several current threads