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 seem to cry for sum types, so imho it is a valid question what's wrong with them, and why Swift prefers enums instead.
I'm sure such a debate already happened, but I haven't seen its arguments... and the ones that come to my mind don't fit to reality:
Enums might be more powerful, but imho Optional<Optional<T>> feels more like a burden.
Sum types, on the other hand, can be composed on the fly and could save us from several, incompatible implementations of trivial things like Result or JSONValue.
Enums in Swift *are* sum types. There are various ergonomic issues with their usability, perhaps, but any implementation of sum types would be different sugar over the same underlying semantic model.
-Joe
···
On Feb 20, 2017, at 12:07 PM, Tino Heth via swift-evolution <swift-evolution@swift.org> 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 relaxed discussion without practical implications isn't the worst thing to have now ;-)
Several current threads seem to cry for sum types, so imho it is a valid question what's wrong with them, and why Swift prefers enums instead.
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 <swift-evolution@swift.org> のメッセージ:
···
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 seem to cry for sum types, so imho it is a valid question what's wrong with them, and why Swift prefers enums instead.
I'm sure such a debate already happened, but I haven't seen its arguments... and the ones that come to my mind don't fit to reality:
Enums might be more powerful, but imho Optional<Optional<T>> feels more like a burden.
Sum types, on the other hand, can be composed on the fly and could save us from several, incompatible implementations of trivial things like Result or JSONValue.
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)
···
Enums in Swift *are* sum types. There are various ergonomic issues with their usability, perhaps, but any implementation of sum types would be different sugar over the same underlying semantic model.
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
···
On Feb 20, 2017, at 10:34 PM, Tino Heth <2th@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)
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 <2th@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.
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.