First of all, thank you for your effort into this! Impressive stuff. I am
not a compiler expert, but the repo made it easier to understand the ideas
you are talking about for someone like me. That being said, my following
questions are a step towards understanding what is and isn't possible in
this design?
*Question 1, **you've made it clear that interfaces can't be types inside a
box type, however, is the opposite true? Can a box type satisfy an
interface?*
```go
type Red struct{}
func (r Red) String() string { return "red"}
type Green struct{}
func (g Green) String() string { return "green" }
type Blue struct{}
func (b Blue) String() string { return "blue"}
type Color box {
Red
Green
Blue
}
...
var c Color
...
```
Does `c` satisfy fmt.Stringer?
*Question 2,* *is there scope to define methods on a `Box` type? Would
defining `func (c Color) String() string { ... }` satisfy `fmt.Stringer`?*
On Monday, 1 September 2025 at 13:50:49 UTC-4 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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/4a8eb891-47e8-4acc-9f18-352e4f3b6fcfn%40googlegroups.com.
