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
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
[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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.