Some immediate thoughts on that:
1. It seems like a strange design decision, to let the importer mess with
*any* exported interface type. In general, Go takes a pretty firm stance
that the semantics of a package should be determined by its author - for
example, you can't add new methods to types. I'm also not completely
convinced it's safe, even with your additional checks. I would have to
think about it more to come up with something specific, but I can well
imagine that the lack of co/contra-variance of `func`, for example, could
lead to surprising results. IMO, the types meant for specialization should
be made explicit (which would be simple enough to add).
2. I'm not super convinced about your argument regarding "local named type
equivalence". I don't think it fully captures the safeties that might be
needed. For example, `struct{}` is comparable and any interface type is
comparable, but the bound type might not be.
3. "Only one place for the binding" IMO misses, that in many cases you
won't need *any* mention of type-arguments in the type-parameters proposal,
as types can be inferred. It's hard to say how often that is the case, how
often you'll need at most one mention and how often you need more than one.
But I don't think claiming this as an advantage of your design is
convincing.
4. The "seamless integration" section seems plain wrong to me. A user of
`container/list` currently needs to type-assert, but if you instantiate it
with a concrete type, those type-assertions will be compile-time errors (as
you can't type-assert concrete types). I don't think that's a pathological
case either - definitionally, you are replacing an interface type with a
concrete type, so this should happen fairly regularly.
5. On the arguments in the "you can not define monomorphic generic types
locally within a package" section, we simply disagree. I don't think
"generic" implies "generally useful" or "belongs in its own package". I
predict that I'll semi-frequently write generic functions that are only
used in a single file. And if you don't like generics, that would seem like
a good thing to me - it means I can keep the definition and usage of that
generic function local and out of any APIs.
6. I think you need to be aware, that while *you* consider it not a goal to
be able to write a generic Max function using `<`, the Go project does. And
while, personally, I wouldn't consider it a non-starter if your design
can't accommodate that, it's certainly a significant drawback over the
type-parameter proposal. Similarly, there is no way to express that a type
must be comparable, which means either a) a generic function can't use it
as a key-type for `map` or b) the result won't be type-safe. Hashmaps are
at the core of many of the algorithms, people would like to implement
generically.
You should also probably be aware, that the type-parameter proposal is
currently in the "likely accept" phase
<https://github.com/golang/go/issues/43651#issuecomment-772744198>. While
this doesn't mean it's a done deal, it does mean the odds of declining it
in favor of a completely new, as of yet undiscussed proposal, are
relatively slim, IMO - especially in light of point 6 above.
On Sun, Feb 7, 2021 at 9:20 PM Martin Leiser <leiser.1...@gmail.com> wrote:
> I follow the discussion about go generics for some time now, but never
> tried using them.
>
> Your conclusion
> > I struggled to grasp generics at the outset of this experiment. They are
> complex in a way that I haven’t encountered in a while with Go: I wasn’t
> sure when to reach for them and when to use another feature of Go.
> is no surprise for me.
>
> Adopting the "c++" or "java" style of generics, which dates back to Ada
> and experimentell languages before that is no good fit for golang in my
> opinion. I am working on a different approach not yet published. You may
> have a look in:
> https://github.com/leiser1960/importbinding/blob/master/README.md
> I do not have a "go2go" implementation for it yet. It is way simpler, and
> there is no doubt when to reach for it.
>
> The basic idea is: golang already has generic types: interface types.
> Simply constrain them to the types you actually want to use with them with.
> It is a simple "opt in" approach. You add a type binding on import, that's
> it. For the "generic" type in the package: Give a name to your types, which
> helps for readability anyway.
>
> And big thanks for your good writeup of the experiment.
>
> Martin Leiser
>
> Ian Lance Taylor schrieb am Freitag, 29. Januar 2021 um 23:13:21 UTC+1:
>
>> On Fri, Jan 29, 2021 at 1:09 PM Ben Burkert <b...@benburkert.com> wrote:
>> >
>> > I wrote a blog post on my experience updating a package to use the
>> > latest proposed generics feature with the go2go tool. My overall
>> > impression is quite good as it was able to solve some existing
>> > problems with the package. Thanks to Go team & gopher community for
>> > all your work making generics happen!
>> >
>> > https://benburkert.com/posts/on-go2-generics/
>>
>> Thanks for the write-up!
>>
>> 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/1f8db11d-56a7-4f16-b6b9-7c7b0b2fe822n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/1f8db11d-56a7-4f16-b6b9-7c7b0b2fe822n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEkBMfHT%3DkMEEqx4UTS6qojHawrNOfON72JdAckUHfzfduh3Ag%40mail.gmail.com.
