Go: Support for Generic Methods

h1fra

slowly implementing all the things they said we didn't need

kardianos

This is great. Will be useful for data access methods! As for the detractors, from the first generics proposal this was called out as a "not now", not never. There were questions of implementation. They aren't a super large team, and they try to do things incrementally and do them well.

nasretdinov

Lack of generic methods was really surprising to me when I was first trying to use generics in Go. Nice to see it being actually implemented

reactordev

This resolves a big gap in generics for most people coming from other languages to go so I completely approve this direction. Not saying use it everywhere but if you must use it, it’s better to have it on the struct than call a module level generic func.

binary132

Chasing a perceived gap between language features and user expectations has been and continues to be the greatest error in the leadership of Go.

samber

OMG. I'm going to recode some of my libraries.

mackross

What a happy surprise today! The amount of times I’ve had to do weird janky package APIs so the API was still reasonable is more than I can count.

xena

This will finally let me make the monad library I've been dreaming of for years. Be afraid.

thayne

> Go doesn't support such generic interface methods because we don't know how to implement (calls of) them, or at least we don't know how to implement them efficiently. I don't really understand this argument. I read the discussion linked to[1], and yeah, monomorphization approaches (whether at compile time, link time, or runtime with JIT) are obviously going to be difficult or impossible, but the reason against using runtime reflection is mostly that it's slow. But that runtime reflection is exactly how you would work around it today . For the Identity example, could the interface be compiled to be basically equivalent to: Identity(any) any and then at the callsite add a cast of the return type to T? I suppose primative non-pointer types add a bit of a wrinkle but even if it generic methods was restricted to pointer types, that's better than nothing. And the number of those types is relatively small, so when the implementation is compiled it could just instantiate method implementations for all the primative types, if they apply, and then maybe remove them if they aren't needed at link time. Of course it's also possible there is some detail I've missed. [1]: https://go.googlesource.com/proposal/+/refs/heads/master/des...

pjmlp

Go becoming a proper 21st century language, is like pulling teeth. It is Apple's school of design, think different, ah, actually, there are reasons why the fence is in the middle of nowhere. Then the design ends up half way there versus being done properly from the beginning.

p0w3n3d

what's wrong with `#define`? <laughing hysterically> nah I'm kidding <after 55 seconds> Seriously, what's wrong with `#define`?