On 19 February 2018 at 17:36, Michael Jones <michael.jo...@gmail.com> wrote: > Matthew Juran wrote: "...but if you use maps, slices, append, make, you are > already using generics." > > This seems deeply insightful to me. Perhaps a better question than the > self-defeatingly open question of "how should Go embrace generics?" would be > "what change would allow maps, slices, append, and make to be implemented as > user code in Go 2?"
It's not just maps, slices, append, and make. Every single operator could be considered too to be "generic" because each operates on an indefinite number of types. But Go gains much from the special-case syntax and semantics associated with each of these language features, IMHO. I'm sure one could make a language where maps, slices, pointers, etc were all just generic types and operations. I'm sure there are many such languages already. Such a language would make for a very different experience than Go provides, though. If maps are just user code in Go 2, what about map literals? If slices are just user code, do we have to be wary that everything that looks like an index operation might have arbitrary side-effects? If channels are just user code, can we still have a select statement? The difficulty of generics is not to provide some number of generic container types, but how to provide a *general* way of specifying operations generically over types. [By the way, I think any discussion on generics in Go is hampered by the fact that the term itself is not well defined. Everyone has their own idea what "generics" might mean, and it's easy to talk at cross purposes.] -- 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.
