I've played with generics a bit more, including the new square
brackets syntax. A few notes (some of the threads have been long, so
apologies if I'm doubling up):
1) I definitely prefer the square brackets syntax. It makes it clear
where you're using type parameters, and IMO it sets them off much more
nicely than parentheses -- especially in method definitions where it
would be parens inside parens.
Related question: why does the current go2go playground allow "func
Ptr[T](v T) *T { return &v }"? Though it turns [T] into [type T] when
you click "Format". Is the former syntax without the "type" keyword
(func Ptr[T]) going to be allowed, even if not encouraged?
2) Speaking of "func Ptr", I'll be really glad when we can write that
simple function generically, rather than all these libraries
implementing this for dozens of different types (e.g., the AWS SDK,
protobufs, a version in our own utility library at work, and I'm sure
we're not the only ones...). See also the proposal to allow the syntax
&T(v) natively to solve this problem:
https://github.com/golang/go/issues/9097 ... I am still a fan of that
proposal, but it'll be much less necessary if this proposal goes
ahead.
3) Defining new container types is fairly straight-forward (here's me
playing with a Map type: https://go2goplay.golang.org/p/y2dGXqsgfEb).
Obviously a basic map type like this isn't needed as Go already has
one, but it'd be similar to build a type-parameterized,
concurrency-safe Map, some kind of ordered dictionary, a set type,
etc. But a couple of things I didn't love:
(a) Needing "interface{}" (on the V type) just feels klunky. I kinda
understand why -- if any of them have a constraint, all of them have
to -- but I wonder if there's a way to avoid this. Maybe "_" instead
of "interface{}"?
(b) When I left off the "comparable" constraint the error message was
a bit cryptic: "invalid map key type K". "But why?", was my immediate
thought. Hopefully it'd be fairly easy to improve that error message.
Maybe something like "type K can't be used as map key; need
'comparable' constraint?"
At work, we've definitely wanted a Set type fairly often; we ended up
defining IntSet, StringSet, and InterfaceSet. So it'll be really nice
to not have to write N set types, or fall back on an interface{}
version. Or maybe there will even be a simple generic set type added
to the stdlib.
4) It seems strange to me that interfaces with type lists are really a
different beast than regular interfaces, and aren't even meaningful as
regular interfaces. (Trying to do that gives the error "interface type
for variable cannot contain type constraints", which is relatively
clear, at least.) As soon as an "interface" has a type list, it's not
really a Go interface anymore (and interfaces with *only* type lists
are not really interfaces at all, just type constraints). This seems
confusing, though I'm not sure what the solution is. Has this been
discussed elsewhere?
5) The ordered Map type shown in the draft design uses a "compare"
function. Won't that mean there's always the performance hit of
calling a function via pointer? Or will the compiler be smart enough
to inline that if you're passing in a function literal (seems
unlikely, as it probably doesn't know it won't change). Then again, I
guess it's only going to be a small performance hit, and is similar to
the "issue" with sort, which isn't actually an issue for most use
cases.
Note that of the above points, #1 and #2 are positives, and #3-5 are
issues. #3a and #3b seem minor or easily fixed, and #5 is probably not
an issue unless it's really performance-sensitive code. But #4 seems
to me like a fairly significant oddity / concern.
A more general question while I'm here: Ian or Robert mentioned on
that recent Go Time podcast something to the effect that people are
pushing generics to its limits. However, most of the examples in the
draft design, and most examples I've seen on the mailing list, are
pretty small examples of simple things. Is there a compilation of
larger or more real-world examples?
Thanks,
Ben
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAL9jXCEv9H5bB9NHZYoJCJoPfdHzYsOee7yWO4fvoAmsYFvXUw%40mail.gmail.com.
