On Mon, Aug 3, 2020 at 1:48 AM Ben Hoyt <benh...@gmail.com> wrote:
>
> 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):
Thanks for the extensive feedback.
> 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?
That is an experiment. We don't seem to need the type keyword for
generic functions. But we do need it for generic types, to avoid
confusion with an array type (but only if there is exactly one type
parameter with no constraint). I'm not personally a big fan of
optional syntax, so we will probably make a decision one way or
another.
> (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{}"?
Another possibility is constraints.Any, although that is no shorter
than interface{}. I'm not sure _ is best; currently _ fairly
consistently means "ignore this value," but in this usage it would
mean something different.
Yet another possibility, going back to the syntax question above, is
requiring that a type parameter for a type alway have a constraint,
which would mean that we would never use the "type" keyword for type
parameters, and define a predeclared identifier "any = 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?"
Thanks. Filed https://golang.org/issue/40551.
> 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?
It's mentioned very briefly at
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-lists-in-interface-types
. I can't recall much discussion on this point. Perhaps any
discussion should go in a different thread, though.
> 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.
I really don't know what the performance effect of this approach will
be. I agree that inlining doesn't seem too likely here. But for more
performance sensitive uses we could perhaps require that the Key type
have a Compare method, in which case inlining would be more likely
under certain implementation techniques.
> 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?
There have been several examples posted to this list, and of course
there is
https://go.googlesource.com/go/+/refs/heads/dev.go2go/src/cmd/go2go/testdata/go2path/src
. But I can't recall seeing any really large real world examples.
To be clear, pushing generics to its limits is fine too.
Ian
--
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/CAOyqgcXkhpps8gxJMt_yGeye8h6Yv_JNU%2Btd9rLJ2%3DCyfzH88g%40mail.gmail.com.
