I'm neutral. + I like the exhaustiveness checking this enables.
+ I like the potential for efficiency if only one of the union types needs to be allocated and there are a large number of possibilities. - I don't like the re-use of the type switch because it hurts the readability in that currently a type switch means an interface is being operated on. With the proposed syntax, it becomes ambiguous: it could be a box or an interface. - I don't like the implicit conversion of a type into a box that the divideBox() example does, as there could be many types that could convert and it is not clear how the reader would or could know which conversion happened. It might be clearer to have names for the fields instead of just types, like a struct. Then they could be assigned to directly. This would also help with serialization and deserialization of a box to disk or network. - I don't like there being a new way to return an error, in effect hiding the fact that an error was returned inside a box. Having multiple return values with one of them being an error has become idiomatic, and I find this helps increase the understandability of code dramatically. open questions: _ what happens when interfaces are choices inside a box? Go values orthogonality and composability, so this would be a natural thing for a developer to do. _ is there some way to use boxes to support chaining when referring deep into a tree of boxes?; so if I would normally say a.b.c.d.someMethod() but it turns out c is a box with a nil pointer (option type), then are the boxes type-checked for compatibility with chaining, and can the error propagate up... On Monday, September 1, 2025 at 6:50:49 PM UTC+1 Cliff wrote: > Hi Gophers! > > I'm trying to find the right place for this work. I spent a couple of > weeks looking at early proposals and dev-team reactions to Discriminated > Unions and Enums as well as feedback from surveys and open/closed > proposals. > > I developed box as a fundamental/orthogonal type in the compiler based on > that research and I thought maybe it would serve as a discussion point - > since it's an implementation that can actually be experimented with. > > https://github.com/CliffsBits/discriminated_unions_and_enums_for_go > > I don't think it will break any existing codebases. -- 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/5b523201-28ed-4332-a5f9-aa9fba6ed65bn%40googlegroups.com.
