On Tue, 2 Sept 2025 at 12:56, Cliff <cliff.programs.sou...@gmail.com> 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 <axel.wa...@googlemail.com> >> 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 golang-nuts+unsubscr...@googlegroups.com. > 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGsx4mLb2Up5QawJQDOKwQGjQPp0CA8bdkT9qyDwWOydw%40mail.gmail.com.
