Thanks for engaging. It was a lot of work. Per observations from 2011,
interfaces in discriminated unions creates a mess. This implementation
avoids that mess by disallowing them. Interfaces are extremely good at
providing polymorphism for behaviors. Sum types/Discriminated unions serve
a different purpose (closed set semantics).
Errors - not being able to return a generic error was a disappointing
consequence of the design - but you can return concretely typed error
structs. It's a different pattern, it's more work, but it offers the safety
guarantees that some vocal subset of people who exist have been talking
about.
To be clear on intent - I wanted to see what it would take to build the
concept in the go compiler. The limitations of the design are what I found
to make it work well with the rest of the language design. Of the language
design tools we have (especially in a procedural context), sum types are
the weakest. The go team chose structs and interfaces from the beginning
and I agree with their assessment that those cover 80% of the use-cases
you'd have in a language. The enum and discriminated union / sum type
workarounds that the community has found work. The only point I'd make to
that - is if so many people have built packages and linters - maybe it's a
missed feature opportunity.
There may be syntactical choices to push a concept like box further from
other constructs in the language visually, but the design choice here was
to keep it familiar. This answers "is there a set of constraints under
which sum types / discriminated unions / enums can easily coexist in go"
and the answer is yes.
I think whatever concept Rob and other designers had of a sum type in 2011
is quite different from what we've seen in Rust, Typescript, Gleam etc.
>From an implementation, language theory, and sanity point of view: putting
non-concrete types in a sum type won't work. If the design principles of go
demand interfaces in sum types, they will never be workable. The one
'escape hatch' for this I could see is using bounded interfaces where you
limit the concrete types that can have that interface and then use those.
type example interface (typea | typeb) {
area() float64
perim() float64
}
You could use an interface like that in a sum type because it is explicitly
bounded, but I think it's an ugly concept that is only necessary if you
want to wedge an open-set behavioral contract concept into a closed set
identity concept. A concept and syntax similar to this explanation (in
support of generics) https://go.dev/blog/intro-generics would be necessary.
it is my opinion that sum types are low-hanging fruit that demand no change
if implemented without interfaces. They remain as complicated and
disruptive as the team has maintained if you do. There is huge value in a
small language and using extension budget for a feature like this this is a
social/value judgement that has technical impacts.
*tldr; Sum types are trivial if you don't allow behavioral contracts or
anonymous types in. Sum types are doable if you allow type restrictions on
interfaces. Sum types are not doable without a) compromise or b) change.*
Thanks for looking y'all - seriously - this was a design exercise for me -
and it helped me understand the go-team's perspective.
On Tuesday, September 2, 2025 at 5:04:36 AM UTC-4 Axel Wagner wrote:
> I should proof-read *before* hitting send:
>
> On Tue, 2 Sept 2025 at 11:00, Axel Wagner <axel.wa...@googlemail.com>
> wrote:
>
>> It seems most likely (based on statements by the Go team) that we would
>> not want to add a new concept that has this much semantic overlap with
>> `interface{ a | b | c }`. But if we did that, the result would lack most of
>> the power people want from it.
>>
>
> To clarify: by "if we did that" I mean "reuse `interface{ a | b | c }`",
> not "add a new concept".
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/f9d02f5d-0fd2-41ef-8882-89aa49cf602an%40googlegroups.com.
