There is hope that they will be added in the future, but solutions to the problems will need to be found first.
There is hope that they will be added in the future, but solutions to the problems will need to be found first.
That's the problem they should fix.
That's the core problem. Anyone who truly understands generics has shown no willingness to work on Go. The only reason it has progressed as far as it has is because a third-party consultant was temporarily hired to develop what was dubbed Featherweight Go to act as a proof of concept.
It turns out that the intersection of people who care about generics in Go and those those who aren't armchair coders unable to comprehend the domain themselves is limited to very few people. As you know well from your armchair.
There was clearly always interest from the project itself. There may have been some random naysayers on the internet who act like they are opposed, but you'll find people acting every way imaginable on the internet. I really doubt anyone actually refrained from working on the project because an internet troll wrote something silly.
was there any major breakthroughs?
If structs support generic methods but interfaces don't then nothing happens, everything just works as you'd expect (whithin those limitations). A method which isn't part of the interface is not under consideration, so the generic methods have no bearing on the interfaces the object could or would implement.
The reverse would be an issue, but this is not.
Actually it does:
"Or, we could decide that parameterized methods do not, in fact, implement interfaces, but then it's much less clear why we need methods at all. If we disregard interfaces, any parameterized method can be implemented as a parameterized function."
https://go.googlesource.com/proposal/+/refs/heads/master/des...
"And even that traversal is not sufficient in the general case when type reflection gets involved, as reflection might look up methods based on strings input by the user. So in general instantiating parameterized methods in the linker might require instantiating every parameterized method for every possible type argument, which seems untenable."
So methods with type parameters would a) not be usable with interfaces and b) not be usable with reflection.