For context, Ian Lance Taylor is a core Go developer and was one of the leads on adding generics to the language. Of course, he has plenty of failed proposals in his background too, so it’s not a sure thing, but it’s definitely more meaningful than JaneRandom4321 writing up a wishlist issue.
This would largely fix one of my great bugbears in the language. It still has a bunch of issues, though: it doesn’t look to cover enumerations, and ideally there’d be a match statement of some kind to allow for pattern matching, which this proposal lacks. I’ve seen a few other proposals for sum types, and hopefully some of the ideas from those might make it into a revised version of this.
I think this proposal strikes the balance between uprooting the type system in Go and doing nothing. The fact that sum types would be interfaces means that most Go code would be unaffected and would seamlessly be able to support the use of sum types with existing semantics, but with the benefit that type authors can define types more accurately.
I think the biggest issue is that this won’t bring about an Option<T>-like revolution to Go, since all sum-types could be nil. But, I think it might be a worthy trade-off.
For context, Ian Lance Taylor is a core Go developer and was one of the leads on adding generics to the language. Of course, he has plenty of failed proposals in his background too, so it’s not a sure thing, but it’s definitely more meaningful than JaneRandom4321 writing up a wishlist issue.
This would largely fix one of my great bugbears in the language. It still has a bunch of issues, though: it doesn’t look to cover enumerations, and ideally there’d be a
matchstatement of some kind to allow for pattern matching, which this proposal lacks. I’ve seen a few other proposals for sum types, and hopefully some of the ideas from those might make it into a revised version of this.I think this proposal strikes the balance between uprooting the type system in Go and doing nothing. The fact that sum types would be interfaces means that most Go code would be unaffected and would seamlessly be able to support the use of sum types with existing semantics, but with the benefit that type authors can define types more accurately.
I think the biggest issue is that this won’t bring about an
Option<T>-like revolution to Go, since all sum-types could benil. But, I think it might be a worthy trade-off.