Maybe I'm misunderstanding what you mean. Can you give me an example? How would you write a Result type in Go? (Result is defined as either Ok(val) or Err(err))
enum result_type {
OK,
ERROR
};
union result_value {
int value;
char *error_message;
};
struct result {
enum result_type tag;
union result_value value;
};
This is not technically closed, but does offer a close enough approximation. Again, not a first-class feature, so there is no expectation if it being true sum types.Go:
type Result interface {
isResult()
}
type OK[T any] struct {
Value T
}
func (OK[T]) isResult() {}
type Error struct {
Message string
}
func (Error) isResult() {}
This one is closed. It perfectly satisfies being sum types. It may not satisfy your opinion of what makes for good ergonomics, but if you want to talk about ergonomics let's use ergonomic words, not type theory words.