John Papandriopoulos

I am most interested in this proposal because I'd like to use chained generic method calls like the OP. It improves the DX for projects like [RxGo](https://github.com/ReactiveX/RxGo/issues/250#issuecomment-1065990503) and I face...

Thanks for the read, @Merovius. After preparing a response to your questions, which you can still read by expanding under **Previous discussion** below, I thought of a way to simplify...

> You are proposing large and significant language changes, which make generic methods behave significantly different from non-generic methods. The benefit of these changes appears to be to permit call...

@ianlancetaylor, if you wish to avoid additions to the language, or [splitting types and interfaces into two phases](https://github.com/golang/go/issues/49085#issuecomment-1188728740), should we then [propose implementation strategies](https://github.com/golang/go/issues/49085#issuecomment-947864049) exclusively? Here is one that I...

@ianlancetaylor I addressed that previously, [where I talk about ammending the laws of reflection](https://github.com/golang/go/issues/49085#issuecomment-1186380446) to rule-out run time instantiation of methods that aren't already part of the program's compile time...

Thanks for conveying your thought process @ianlancetaylor. It definately helps, as it's now pretty clear that this feature hinges on reflection support... > I've been thinking about this problem off...

@aarzilli, I'm not proposing to use GC Shapes. I'm sorry if my last message was unclear: I was proposing to use the pure Dictionaries approach; see the link in my...

> You still need to do codegen to instantiate a dictionary: `func (s *S) Equals[T any](a, b T) { return a == b }` needs an equality function for whatever...

@Merovius, perhaps [my last suggestion](https://github.com/golang/go/issues/49085#issuecomment-1191081120) wasn't so clear, as @aarzilli was thrown off by it too. I make an effort to trim my comments before posting, sometimes at the expense...

[Quotes below from @ianlancetaylor] > > we also include one additional instantiation per type-parameterized method based on the pure dictionary approach. > > This does not give implementations the freedom...