According to the description of the Go generalization proposal, Go does not support generalized methods:No parameterized methods. The main reason Go generic processing is implemented at compile time, and generic methods are difficult to determine how the generic scheme should be instantiated without contextual analysis and inference at compile time, or even impossible to determine, resulting in the current (Go 1.18) Go implementation not supporting generic schemes.
However, the lack of generic methods more or less brings a tinge of sadness to programmers and is particularly inconvenient to use under some scenarios. I have recently seen several problems caused by the lack of generic methods, which I will summarize in this article and discuss with you.
It’s a little comforting to know that Ian Lance Taylor and Ian Lance Taylor didn’t put the word out that maybe in some version, generic methods are supported again:
So while parameterized methods seem clearly useful at first glance, we would have to decide what they mean and how to implement that.
Why is the current Go generic bad at implementing generic methods?
Consider the following example, where there are four packages:
Everything looks fine, but the problem is that
package p3 doesn’t know the type of
p1.S.Identity if it is not called anywhere else in the program. There is no way to generate code for
p1.S.Identity[int] with the current Go compiler implementation.
Yes, this scenario is recognizable at compile time if the go compiler is made more complex, but it requires traversing the entire call chain in order to generate all possible generic methods, which makes a big adjustment to compile time and compiler complexity. Another point is that if the code is called by reflection, the compiler may miss some implementations of generic methods, which can be very annoying.
What if it is implemented at runtime? It would require techniques such as JIT or reflection, which would cause a degradation in runtime performance.
Hard to implement, huh? What if it is specified that generic methods cannot implement interfaces? Then what is the point of having such generic methods?
So there’s no good means to implement generic methods, so I’ll put it aside for now.
If it is really necessary, you can implement generic methods by implementing generic functions and passing the method’s receiver as the first argument.
This can solve part of the problem, but it is more or less troublesome in the process of using it.
Because of the lack of generic methods, people have encountered trouble when they started using them, and recently I have seen several consecutive articles about this, such as the following ones.
Facilitator pattern by rakyll
Yesterday rakyll wrote an article https://rakyll.org/generics-facilititators/ , describing the difficulties she encountered and how to solve them. This is what prompted me to summarize the cases I’ve seen over the past few days.
If you are familiar with other programming languages, you may have seen similar code below when using the orm framework, implementing generic methods for some kind of object lookup:
Because Go lacks an implementation of generic methods, you can’t implement generic
All methods, so how do you do that? One way is to implement the
All function, and another is to implement what rakyll calls the
Facilitator pattern :
The function implementation gives a sense of powerlessness, a lack of homing, a sense of not having an object, and this implementation, which generates a specific type of Querier[T],
All method has the feeling of a generic type (although it is actually a Receiver generic type)
Some students are familiar with the official Go extension library x/sync/singleflight, which is a good solution for It is often used in cache access and microservice access processing.
To support arbitrary types, its internal implementation uses the
any) type for representation and handling:
Five days ago, someone transformed it into a generic way: marwan-at-work/singleflight, and the above code was used to change it to the following way:
It is equivalent to transform the Group into a generic type, instead of implementing the generic method
Do (of course, Go generic can not be achieved at present).
This processing and the above rakyll processing type, are generated generic types, through the Receiver to implement the processing of generic methods.
But for this way, one bad thing is that you have to generate a special object for each type, which is slightly troublesome.
Earlier in the discussion about generics, it was suggested that the lack of generic methods made it difficult for Go to implement a map reduce-like library, and I forget exactly where it was mentioned.
For example, the following implementation of an iter map reduce:
In this case the user wants to pass in an arbitrary
K, the original
T type iter into
K type iter, this does not want to support other generalized language so well implemented.