3 ms·
I’m talking about formal generics, where there are type system mechanisms for specifying type parameters and constraints. I suppose there are really three thing
by cle 5y ago
I’m talking about formal generics, where there are type system mechanisms for specifying type parameters and constraints. I suppose there are really three things we’re considering here: the generic implementation that operates on some arbitrary type, the concretization that has only concrete types, and a generic type specification which is only required if the compiler emits the concretization instead of the programmer. (I'm ignoring interfaces as they aren't really relevant here, that I can see. And hopefully I'm using the right terminology here.)
What I’m arguing is that for most cases, the implementation and concretization are so easy to write by hand, are safe enough, and perform well enough, that I don’t think the downsides of having the compiler emit the concretizations are worth it. The downsides being the new complex language primitives that have lots of consequences that trickle out to the compiler, runtime, and ecosystem.
- nicoburns 5y ago> a generic type specification which is only required if the compiler emits the concretization instead of the programmer. (I'm ignoring interfaces as they aren't really relevant here, that I can see. And hopefully I'm using the right terminology here.) Unless I'm mistaken, the "generic type specifications" are just interfaces. Instead of specifying the concrete type of a function parameter, you specify which interface it needs to implement, and then everything else is the same (except you may need to define getters/setters if you need access to struct fields). There's no need to have a new language primitive. That's certainly how Rust does it anyway. And given that Go's interfaces are structurally typed, it'll be even simpler in Go. I don't really understand the argument that generics are complex. As far as I can see, they're super simple.