[jerf]

Not sure what you mean by "no generics on interfaces"? https://go.dev/play/p/jGINeUt1JTE

Also echoing not sure what you mean by "no consistency in formatting or imports". It is increasingly difficult to use Go without gofmt getting run, since I have to imagine fewer and fewer people nowadays are using an editor that has neither custom support for their language nor LSP integration, and integration with gopls automatically runs goimports on save.

[cybrexalpha]

> Not sure what you mean by "no generics on interfaces"?

I didn't word this very well. You can have a generic interface, and functions on that interface can refer to generic types. But you can't have a generic method on an interface that uses a different generic type. For example you can't have:

``` type YieldThing[T any] interface { Yield() T DoOperation[U any](U) } ```

[jerf]

I figured based on your comment you meant something by it.

In which case I'd point out that it goes beyond interfaces and Go just doesn't permit that in general, for those who are playing along. All generics are always fully instantiated. You can have a

    type Holder[T any, U any] struct {
        Val1 T
        Val2 U
    }

but you can never have anything like a variable of type Holder[int], with a type-currying effect or something where the U bit is still unbound, or a bare variable of type "Holder" without any further parameters. All types within the language are always fully instantiated after compile.

[cybrexalpha]

Yeah I get it. I've found workarounds in the past. But it's always involved some friction.

In general, Go's generics are a huge step forward though. So I'm not that annoyed about it.

[foldr]

There are good reasons for not allowing generic methods:

https://go.googlesource.com/proposal/+/refs/heads/master/des...

[Nijikokun]

Realistically the reasons are this:

> So while parameterized methods seem clearly useful at first glance, we would have to decide what they mean and how to implement that.

They just didn't want to decide what they mean or how to implement them.

[foldr]

Right, but that's because it is not obvious what they should mean or how to implement them. In particular, it seems that intolerable complications to the linker would be required. Contrast that with, say, a proposal to add a more concise syntax to Go for anonymous functions. Everyone can see exactly what that would mean and how it would be implemented.

I'm not saying that Go should never add generic methods to the language. But it's at least reasonable to hold off from doing so until these issues are clarified.

There is a concise explanation of the central problem in a comment in the issue thread:

> The crux of the problem is that with a parametric method, the generated code for the body depends on the type-parameter (e.g. addition on integers requires different CPU instructions than addition of floating point numbers). So for a generic method call to succeed, you either need to know all combinations of type-arguments when compiling the body (so that you can generate all bodies in advance), or you need to know all possible concrete types that a dynamic call could get dispatched to, when compiling the call (so you can generate the bodies on demand). The example from the design doc breaks that: The method call is via an interface, so it can dispatch to many concrete types and the concrete type is passed as an interface, so the compiler doesn't know the call sites.

Rust allows generic methods on traits but doesn't allow these traits to be instantiated as trait objects. Perhaps Go could do something similar. https://docs.rs/erased-generic-trait/latest/erased_generic_t.... But it's far from obvious to me that this would be a good idea for Go, and I'm glad the Go team haven't rushed into anything here.