>generic functions defined on types cannot use generic parameters that aren't defined on that type, for example
This is bonkers to me, why???
This is bonkers to me, why???
C# can do this because it has a JIT and can compile such methods dynamically (and rejig vtable if needed). In an AOT-compiled language like Go, it would either need to treat this pessimistically and instantiate every possible implementation of every method that could be virtually dispatched anywhere in the program, or else it needs to do what Swift does and generate code that is generic at runtime - i.e. pass some kind of type descriptor with information like size of type and everything else that's needed to handle it, and then the code would look at that type descriptor and do the right thing; this works, but it's non-trivial, and generated code is very slow.
There is nothing (wrt language) that cannot be done with C++.
Indeed this involves expensive lookup for generic virtual methods. It is also not very friendly to NAOT's binary size once you start having many generic instantiations of the type with such method(s). In the case of Go, I'd assume it will require making both its VM and code reachability analysis more complex to make it work, and they decided to simply shift the responsibility and ceremony onto the programmer which is the standard in Go design.
". They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."
https://go.googlesource.com/proposal/+/master/design/go2draf...
It seems there are tons of things the designers banned because they are bad in C, and didn’t supply any replacement because the C++ version is overly complicated or hard to use, and they weren’t aware of anything better.
Metaprogramming is a perfect example. C macros are bad, C++ metaprogramming facilities are baroque, so let’s not have any metaprogramming features whatsoever and tell people to rely on code generations or reflection instead.
(There is a very curious but prevalent phenomena where highly intelligent people let a governing ideology do the thinking for them and refuse to countenance ideologically discordant possibilities. (Ancient too, as we see from the ideological reaction of Pythagorean's to existence of √2..))
Highly intelligent people experience having correct intuition -- a product of reasoning occurring at below a conscious level -- a lot, to the point where they may learn to intrinsically trust their intuition to be correct and be highly confident it will prove correct. However, while intuition can often be a manifestation of that kind of unconscious reasoning, it can also be a product of aesthetic/ideological (really, the same thing) preference, among other biases.
Work started in February 1999, while .NET 1.0 was released in October 2021.
https://learn.microsoft.com/en-us/archive/blogs/dsyme/netc-g...
- need overloading to support instantiation - need type functions/associated types. For example what type is inside this container? - need operator overloading so you can substitute generic types into assignment expressions. For example notions of equality. - need duck typing or traits to communicate capabilities
The two simplifications which have historically worked are to use dynamic types, or to use code generators.
In Haskell this is something like map :: (a->b) -> C a -> C b
Can you share what that would like in Go with type classes?
You can also define an fmap interface that doesn't actually map the type, but can apply function that do not change the type: https://go.dev/play/p/836wr3nuw4U
But currently I don't think it's possible to combine this. That is have an fmap as it is in Haskell. You would need to capability to add generic arguments to an interface. It could look something like this: