Axel Wagner

FWIW here's another way to look at it, which IMO speaks in favor of talking about passing around generic functions/types before tackling generic methods. On the implementation level, an interface...

> For instance, does `HasIntIdentity` implement `HasIdentity`? No. That would make no sense. However, the other way around it's a valid question to ask. But 1. I think the obvious...

> I may be mistaken but it makes more sense to me to consider whether HasIntIdentity implements HasIdentity than the opposite. `HasIntIdentity` means you have a method `Identity(int) int`. `HasIdentity`...

@atdiar There are three different interfaces we could consider ```go type HasIdentity1 interface { Identity[T any](T) T } type HasIdentity2[T any] interface{ Identity(T) T } type HasIntIdentity interface{ Identity(int) int...

@atdiar If `HasIntIdentity` implements `HasIdentity`, this code would be presumably correct, so what would it do? ```go type HasIdentity interface{ Identity[T any](T) T } type HasIntIdentity interface{ Identity(int) int }...

@jpap > I haven't seen disagreement here on the importance and utility of Part 1, despite your generics design suggesting that […] I think the point is not that there...

Just to put more spanners into the works: For better or worse, [plugin](https://pkg.go.dev/plugin) exists. So the compiler does not, in general, know all the code that is compiled into a...

@jpap It's not that it *can't* be done at runtime. It's that it *has* to be done at runtime and we don't want to prescribe a particular implementation strategy. That's...

(That's FWIW, why suggesting a specific implementation strategy won't really help. We'd need a way to describe how to spec this out so we *don't* need a specific implementation strategy)

@mccolljr > To categorize the benefit of this feature as "method chaining" seems like it is at best a failure to understand the community's desires here, and at worst an...