Given all the challenges associated with generics, it might be productive to
follow up on this alternative approach of identifying a (small set) of new
primitive containers and functions that would otherwise have been written using
generics, that are of sufficiently general applicability as to merit inclusion
in Go2? I know this kind of discussion is had frequently on this list, e.g.,
recently in the case of tuples and ternary expressions, and the outcome is
usually a pretty convincing “not gonna happen”, but MAYBE in the light of the
generics discussion there might be some fresh insights along these lines?
It seems like one of the fundamental reasons generics are so “contrary” for Go
is that they require exposing a bunch of low-level internal special-case logic
(e.g., operator semantics, etc) in a “meta” explicit way. Doing so in a clean,
simple, elegant way may be impossible. The current Go1 alternative strategy is
to bury all that logic well out-of-sight and provide a simple, elegant “magic”
set of language primitives that seamlessly interoperate with all the other
basic types. For those things that are supported in this way, the result is
pure joy and simplicity :) So, a logical alternative to generics is to think
about anything of sufficient generality that is missing, and just add it in
with the same kind of existing magic.
Another way of framing the issue is: if you give people generics, they will
each write the same kind of functionality in slightly different ways. Instead,
the “Go” way is to figure out the *best* way to do something, and build that
right on into the language as a primitive, which fully interoperates and deals
with all the necessary idiosyncrasies of the other types. I doubt anyone would
argue that the existing “minimal basis set” of functionality is truly minimal
and truly covers the vast majority of needs.
The list of plausible additions is likely quite small, and the draft generics
proposal suggests what most of these might be:
* binary trees (llrb?) — can anyone really argue AGAINST this?
* sets — really map[T]struct{} seems fine here — probably not worth it?
* linked lists?? probably not given llrb? also I’ve written many stacks and
they seem trivial and painless using slices..
* tensors (n-dimensional arrays) — this would be GREAT for numerical stuff —
there is an existing heroic implementation https://github.com/gorgonia/tensor
but a minimal core builtin support for the basic slice-level functionality
extended to multiple dimensions would be really nice! Here’s a proposal:
https://go.googlesource.com/proposal/+/master/design/6282-table-data.md
Functions:
* insert() primitive for slices — I wasn’t able to find prior discussion of
this, but this is the ONLY major pain point for me in dealing with slices — it
is 3 repetitive, relatively opaque lines of code every time, and seems well
worth the “investment” in a new keyword.. I did find some debate about whether
delete() should operate on slices too — seems like that would be a simple
semantic convenience that makes code more explicit and the counter-arguments
from the previous debate weren’t that strong IMO
https://grokbase.com/t/gg/golang-nuts/1366rkp7ef/go-nuts-why-not-provide-a-delete-function-in-slices-just-like-in-maps
* max(), min(), abs() — how about it? these seem like the main focus of
generics discussion, and are a “safe” special case form of the ternary
operator. When I first found out that there wasn’t a max operator for ints in
Go I was really shocked.. I got over it, but still, these are really basic
mathematical operators that I use all the time..
* most of the other examples in the generics proposal seem like such trivial
one-liners (sorting, map / reduce, the various channel functions) that it
doesn’t quite seem worth it…
Anyway, that is really it for my list — if these were in the language, it would
make my code easier and simpler to write and understand. I’m not sure I could
say the same for any of the existing generics proposals.. :)
- Randy
> On Sep 18, 2018, at 2:05 PM, Michael Jones <michael.jo...@gmail.com> wrote:
>
> I believe average Go code will be better if there are map-quality llrb trees,
> stacks, sets, ... for the taking, just as if tuples were a first class thing.
> There were horrors in STL's evolution, but by now, everyone gets such data
> structures right the first time they use them, just as they do now with Go
> maps.
>
--
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.
