3 ms·
"or even better: force listing all the types that are currently using this generic" This is a bad idea. Imagine a generic hash map, we surely want it to work w
by protomolecule 7y ago
"or even better: force listing all the types that are currently using this generic"
This is a bad idea. Imagine a generic hash map, we surely want it to work with any value type.
- baby 7y agoTrue. I’m trying to find a solution to the biggest problem of generics which is imo that you can’t understand how it’s being used when reading one. It’s fine if the function doesn’t do much. But if it’s nesting generics, or doing anything complex, then not using a union of interfaces make it really hard to understand code. I’d like if Golang would add unions of interfaces. But generics? I’m not sure if it’s a good idea. Or maybe if you import a package that have some generic functions, you would need to add a declaration that list what the types using these generics are. Import “stuffWithGeneric{ thing(K, V) -> (egg, bacon), thing(K, V) -> (int, string), }”
- protomolecule 7y agoImagine you have a non-generic function, for example, `parseJsonData(string)`, how would you understand how it is being used? It can be called with all sorts of input. Is the problem you are describing different?
- baby 7y agoThat’s true. Usually the name of the argument indicates how it is used. Without it you are lost. I feel like what really tricks me is this kind of code: parseJsonData(t T) Now neither the type nor the argument name help you understanding the purpose of the function.
- protomolecule 7y agoIn this case wouldn't the name of a contract be enough? Or, perhaps, not enough, but informative to the same degree?
- spion 7y agoThe one-letter "naming convention" used for generic types by most developers is very unfortunate.
- protomolecule 7y agoWhy? There are usually only one or two of them, it's like using `i` for loops instead of `indexOfElement`.
- spion 7y agoType parameters are more like function arguments, not loop variables. There is often one or two arguments too but they are not as local (contained) as loop variables.
- thomasz 7y agoThis is a problem with template metaprogramming, not with generics. Code using generics isn’t less obvious than code using only specialized types. On the contrary: You work with strong typing instead of using interface {} everywhere.
- baby 7y agoPeople use interface{} everywhere because union interfaces don’t exist in Golang. If union interfaces were a thing you could be writting func thing(a car+plane)
- spion 7y agoYou can substitute all generically typed items with the type interface {}. That's how much is known about the object - basically nothing. You can substitute generics that conform to a contract by their contract.