There are no subtypes in go, so no covariance or contravariance, which explained a lot of limitations of Go type system. The problem is that some level of covariance is hardcoded in the compiler (string to []byte ...) which makes me think that go designers understand the value of it and know that there are cases where it is needed. It just the same problem as generics vs append. append is a generic function of type append([]T,T...)[]T which behavior is hardcoded in the compiler instead of being generalized. Go designers understand the value of generics in that specific case without letting the user define their own functions with the exact same behavior.
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) All languages are opinionated, I think that adjective doesn't match Go features. Go is a language that is "restricted" but bear with me. The problem with being fine with that fact is that, while Go has these restrictions, Go allows a lot of dynamic behavior at runtime through reflection (with a speed cost, though caching definitely helps) which is a paradox for a statically typed language. The temptation of using reflection to work around language restrictions becomes huge every time one is confronted to these limitations. It would be interesting to know if allowing(or not) reflection in userland was debated among Go designers at some point. Regards. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
