> Technically ("well, acksually"), Go doesn't "lack generics".
Yes it does, generics are types. You bet all these append(T[A],A)T[A] tricks are hard-coded in the compiler in an adhoc fashion, and not part of Go's type system.
I’ve heard this « go has generic it just doesn’t let you access it » argument so many times, it would be really good if someone could actually point to the piece of compiler code that define those generic capabilities.
My guess is they don’t have anything usable by the end user any way, otherwise they wouldn’t spend so much time thinking about a design for go 2. It probably means whatever is in the compiler isn’t that elegant, nor reusable.
Implementation choices are just that. Arguments about whether the language does or does not have generics should refer to properties of the language, not properties of the compiler.
The argument indeed isn’t about the language, but about the reason why the language doesn’t have generics. The fact that some predefined functions are developped using something looking like a generic type system, or not, is an interesting factor in this conversation.
Yes it does, generics are types. You bet all these append(T[A],A)T[A] tricks are hard-coded in the compiler in an adhoc fashion, and not part of Go's type system.