FWIW you can model a sum as a product plus a tag. That is, you can implement
Maybe[T] = None | Some T
match m {
case None:
// do thing
case Some v:
// do thing with v
}
as
type Maybe[T any] struct {
Case int // 0 or 1
None struct{}
Some T
}
switch m.Case {
case 0:
// do thing
case 1:
v := m.Some
// do thing with v
}
This seems fairly straight forward, and it would work fine with interfaces.
It's not an incredibly efficient implementation. But (especially if we
allow reordering of struct fields, which I believe is something the Go team
is considering) the compiler can always pack things more efficiently.
On Tue, 2 Sept 2025 at 13:12, Axel Wagner <[email protected]>
wrote:
> On Tue, 2 Sept 2025 at 12:56, Cliff <[email protected]>
> wrote:
>
>> From an implementation, language theory, and sanity point of view:
>> putting non-concrete types in a sum type won't work. If the design
>> principles of go demand interfaces in sum types, they will never be
>> workable.
>
>
> Why not? In a union they don't work, but in a sum I can't see a reason why
> they wouldn't work. If I'm overlooking something, I'd be super interested
> (I intend to give a talk on this topic soon, so I would want to avoid being
> wrong).
>
> Have you seen https://github.com/golang/go/issues/54685 ? It has a very
> well-worked design for how sum types could work in Go. I have not found a
> problem with it and it doesn't preclude using interfaces.
>
>
>> The one 'escape hatch' for this I could see is using bounded interfaces
>> where you limit the concrete types that can have that interface and then
>> use those.
>>
>>
>> type example interface (typea | typeb) {
>> area() float64
>> perim() float64
>> }
>>
>> You could use an interface like that in a sum type because it is
>> explicitly bounded, but I think it's an ugly concept that is only necessary
>> if you want to wedge an open-set behavioral contract concept into a closed
>> set identity concept. A concept and syntax similar to this explanation (in
>> support of generics) https://go.dev/blog/intro-generics would be
>> necessary.
>>
>> it is my opinion that sum types are low-hanging fruit that demand no
>> change if implemented without interfaces. They remain as complicated and
>> disruptive as the team has maintained if you do. There is huge value in a
>> small language and using extension budget for a feature like this this is a
>> social/value judgement that has technical impacts.
>>
>> *tldr; Sum types are trivial if you don't allow behavioral contracts or
>> anonymous types in. Sum types are doable if you allow type restrictions on
>> interfaces. Sum types are not doable without a) compromise or b) change.*
>>
>> Thanks for looking y'all - seriously - this was a design exercise for me
>> - and it helped me understand the go-team's perspective.
>>
>> On Tuesday, September 2, 2025 at 5:04:36 AM UTC-4 Axel Wagner wrote:
>>
>>> I should proof-read *before* hitting send:
>>>
>>> On Tue, 2 Sept 2025 at 11:00, Axel Wagner <[email protected]>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> To clarify: by "if we did that" I mean "reuse `interface{ a | b | c }`",
>>> not "add a new concept".
>>>
>> --
>> 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/f9d02f5d-0fd2-41ef-8882-89aa49cf602an%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/f9d02f5d-0fd2-41ef-8882-89aa49cf602an%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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFOEiA92Oe1_0t-_dA6hJacPFBxsX%3DpQGCKqkYB4Hj0dg%40mail.gmail.com.
