Implementing generic methods with boxing

[Ethan Reesor]

I'm writing this here instead of on the issue since IMO GitHub is not a good structure for discussions and that issue has so much noise.

As I understand it, the fundamental issue with generic methods (that can satisfy interfaces) is: Given that we cannot enumerate all potential calls short of enumerating the entire span of valid combinations, an implementation of generic methods must necessarily be able to handle arbitrary types passed to the type parameters. Is this a correct summary? From there, if I understand correctly, the chain of reasoning is: the runtime must be able to handle an arbitrary (valid) type passed to a type parameter, thus the runtime must be able to generate code, but requiring runtime code generation is not on the table.

It's the link from arbitrary type arguments to we must generate code that I want to look at. Can we get around that with boxing? Given a generic type parameter T (of the method), can we box values of type T as an interface type? As in, arguments passed to and variables within the method that are of type T are boxed as interface values. That way, the values will always have a fixed size - the size of an interface value. Of course I'm pretty sure this would require generating an implicit interface type for T. But if there are no fundamental issues, that seems like a solvable problem - calling a generic method would involve the same kind of interface satisfiability checks that any other assignment to an interface type does.

One issue that occurs to me is assigning values to maps and slices. For example, a generic method that maps a slice of type A (parameter of the type) to a slice of type B (parameter of the method). But I think that can be solved by adding AssignToSlice and AssignToMap to the implicit interface. Then the compiler can generate an implementation of the interface that handles those assignments.

[Axel Wagner]

On Tue, Mar 26, 2024 at 7:18 PM Ethan Reesor <ethan....@gmail.com> wrote:

I'm writing this here instead of on the issue since IMO GitHub is not a good structure for discussions and that issue has so much noise.

As I understand it, the fundamental issue with generic methods (that can satisfy interfaces) is: Given that we cannot enumerate all potential calls short of enumerating the entire span of valid combinations, an implementation of generic methods must necessarily be able to handle arbitrary types passed to the type parameters. Is this a correct summary? From there, if I understand correctly, the chain of reasoning is: the runtime must be able to handle an arbitrary (valid) type passed to a type parameter, thus the runtime must be able to generate code, but requiring runtime code generation is not on the table.

It's the link from arbitrary type arguments to we must generate code that I want to look at. Can we get around that with boxing?

Yes, but one of the fundamental design criteria behind generics is to not require specific implementation strategies.

https://go.googlesource.com/proposal/+/HEAD/design/43651-type-parameters.md#implementation