> Interface defines an open class of types

But can also define a closed set of types, perfectly satisfying "sum types".

> This enables different syntax, like the match expression to be used, in which you exhaustively list all the variants.

Go does not provide this out of the box, but that is not prerequisite for sum types. The mathematical theory says nothing about "the compiler must produce an error if the user doesn't match call cases". There is sufficient information provided by the sum types if you wish to add this to your build chain yourself, of course.

▲

josephg 2 hours ago | parent [-]

By that definition a void* pointer in C is a sum type. By that definition assembly has sum types.

This argument feels like the “we have sum types at home” meme. Ergonomics matter.

I write a lot of rust. Rust has traits which are similar to Go’s interfaces. But the features aren’t the same, and I use enum all the time. (I also use trait all the time, but I use trait and enum for different things).

	▲	9rx 3 minutes ago \| parent [-]
		> By that definition a void pointer in C is a sum type.* No. void * is essentially equivalent to any in Go, which isn't sum type either. You can construct sum types in C by combining structs and unions, but it is not an out of the box feature like in Go. > Ergonomics matter. Not to math it doesn't.