I got hit by a car last night. As I was sitting in the emergency room I 
realized the answer to Russ Cox's 2011 
riddle https://groups.google.com/g/golang-nuts/c/0bcyZaL3T8E - you 
disambiguate as you're placing the item in the sum-type/box. 

type RW union {
io.Reader
io.Writer
}

mean? Or is it disallowed?
(That would be pretty unfortunate.)

What happens if you have

var r io.Reader = os.Stdin  // an *os.File
var rw RW = r* <- io.Reader //this disambiguation is actually not necessary 
- if you placed it as an io.Reader it should come out as an io.Reader - but 
if the os.Stdin had been placed 'raw' it would have needed a disambiguation 
tag. I'm not suggesting syntax (as, inShapeOf... a bunch of syntax is 
possible). Basically - it's manually setting the tag on the discriminated 
union so there is no ambiguity on retrieval. *

*I haven't written disambiguation syntax - I'd be happy to revisit the 
project if someone wants a 'complete' tool to play with - but with that as 
an option - I consider simple sum-types solved. The compiler source-code 
already has a really solid example that was introduced for generics. I 
think the easiest case forward would be to no longer call {type1|type2} an 
interface for generics - find a new word - and add disambiguation logic on 
insert for the classic Russ Cox case, or use 'box' as a keyword because 
it's neat.*

(Apologies - I don't know how to quote properly) 

Regarding https://github.com/golang/go/issues/54685 - sigma types. They're 
more complex and powerful - they could work if that's what you guys want. I 
prefer simple (I think the box concept is simple).
*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? **Answer: 
*as implemented - boxes only expose the methods to get a concrete type out 
of a box - they are not 'the thing itself', they're just a wrapper for a 
variable. 
*Question 2,* 
*is there scope to define methods on a `Box` type? Would defining `func (c 
Color) String() string { ... }` satisfy `fmt.Stringer`?**Answer: *Same as 
above - boxes are really dumb containers. 

On Wednesday, September 3, 2025 at 1:29:33 AM UTC-4 Sandesh Gade wrote:

> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/07e63e1e-821b-45d2-bf67-f0654bb713ddn%40googlegroups.com.

Reply via email to