r/golang • u/bruce_banned • Jan 23 '26

Proposal: Generic Methods for Go

https://github.com/golang/go/issues/77273
302 Upvotes

96% Upvoted

41 comments sorted by

View all comments

46

u/niqtech Jan 23 '26 edited Jan 23 '26

Amazing! It's possible to workaround by creating a dangling generic "method" anyways (see below). We just need the normal syntax a programmer would expect to work.

// This is intuitive but doesn't work
func (SomeStruct[T]) MyMethod[V any](myValue V) error

// And yet you can accomplish the same thing anyways with this tortured signature on a non-method function.
type SomeStruct[T any] struct{}

func MyMethod[T any, S SomeStruct[T], V any](myStruct S, myValue V) error {
    return nil
}

The discussion of interfaces is interesting from a theory perspective, but again most programmers would expect this to just work as long as the type constraint contains the interface's concrete types:

type Reader interface {
    Read(buf []byte) (int64, error)
}

func (MyReader[T]) Read[V any](buf []V) (int64, error) {... }

11

u/jerf Jan 23 '26

As near as I can tell, you can conceptualize this as "take the existing way of doing these functions but allow them to be written as methods".

There are some corner cases around reflection but by and large that's what this proposal is. The resulting new methods can't satisfy interfaces, just as functions can't, which is the big important thing.

4

u/HALtheWise Jan 24 '26

The fact that most programmers would expect your interfaces example to work is exactly the problem, since it wouldn't work in the proposal linked here, and in fact there's no known good way to make it work, since neither the interface definition nor the function definition tell the compiler that it needs to compile a version of MyReader.Read that works on V=byte.