> 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.
Yeah, I agree -- I think having it optional for functions but not for
types is a bit confusing. I do like the fact that you don't need to
write "type" or list the constraints on the type in methods, though --
that would be really verbose.
> 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.
Yeah, I don't think 'import "constraints"' and then "constraints.Any"
is any (ahem) better. Maybe slightly more self-documenting.
> 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{}".
Interesting idea, I kinda like that. At first thought, when there's no
constraints I think "[type T]" is slightly clearer than "[T any]". But
then again, this latter syntax parallels normal types where you always
have to specify it, e.g., "v int", "x interface{}", etc.
I notice in one of the examples in the repo you define a short name:
"type any interface{}". Which at first seems like a good idea, but
then unless "any" is built in or this becomes a well-known idiom, it
won't be as self-documenting. Other people will have to look up the
definition to see "oh, I see, this is just short-hand for an empty
constraint".
> > (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.
Thanks!
> 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.
Thanks. I might start that as a separate thread, then, and see if
anyone has any thoughts.
> 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.
Thanks. I actually didn't know about / had forgotten about this
repository of examples. I realize parts of many of them are in the
draft design, but it's nice to see them all in one place.
-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/CAL9jXCEpUiyHn3nw%3D1n8FuFZi2rM0Sc%3Durw%3D8RJXEOFy0vcBrQ%40mail.gmail.com.
