Hi,
On Tue, 2 Sept 2025 at 00:48, Jason E. Aten <j.e.a...@gmail.com> wrote:
> I'm neutral.
>
> + I like the exhaustiveness checking this enables.
> […]
> _ 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.
>
I believe these two are incompatible under this approach - or at least, if
you want both, you need to employ a SAT solver (see below).
> - 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.
>
Yes, this is the core design decision to make `box` a union type, instead
of a sum type. It is also this decision that means you can't have both
interfaces as cases *and* exhaustiveness checks. Basically, because in a
union type the cases can overlap (if we allow interfaces), a switch
statement becomes a boolean formula in Disjunctive Normal Form (every
interface case is a boolean variable of "has method X and Y and Z". You can
model negation by including conflicting method signatures). Proving that
all cases are covered requires proving that this formula is a tautology,
which requires proving that it's negation is not satisfiable. The negation
of a DNF formula is in CNF and proving whether or not a CNF formula is
satisfiable is NP-complete.
Sum types solve this, as there is always a finite, non-overlapping list of
cases, so proving that a switch/match covers all cases basically just means
ORing and ANDing a bunch of bit masks and check that the OR has all 1s and
the AND has all 0s. Sum types are significantly more powerful and *if* we
introduced a new syntax, I would hope that we would use sum types. I think
the only reason we should use union types is because we want to reuse the
`interface{ a | b | c }` syntax (which has other problems as well, like
requiring a `nil` zero value).
I will say, that I believe it is these kinds of design questions that are
holding up any sort of variants in Go. 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. A lot of
people have been clear, that in their opinion it would not be worth
bothering at all in that case.
If we could agree *what* we want, I don't think the implementation would
really be the hurdle. But the effort is impressive.
> - 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:
>
>
>
> _ 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
> <https://groups.google.com/d/msgid/golang-nuts/5b523201-28ed-4332-a5f9-aa9fba6ed65bn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEkBMfHbBwymzPPhvOvtX3fK9ooAtWa4qkM8Q9YK3kv53H1c5A%40mail.gmail.com.
