[generics] notes on adding generics to a package

[Ben Burkert]

Hi Gophers,

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/

Cheers,
-Ben

[Ian Lance Taylor]

Thanks for the write-up!

Ian

[Martin Leiser]

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

[Axel Wagner]

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. 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.

--
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...@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.

[Martin Leiser]

Am 07.02.2021 um 22:36 schrieb 'Axel Wagner' via golang-nuts:

Some immediate thoughts on that:

1. It seems like a strange design decision, to let the importer mess with *any* exported interface type.

it is, but it is simple.

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.

My argument is as follows: The generic package can not use any property of the parameter type, i.e. the interface type because of the additional check. The interface type by itself constrains the usage to the methods of the type plus assignment from any compatible type. The last property is taken away with the additional check.

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.

No overloading in go up to now, how should this happen?

IMO, the types meant for specialization should be made explicit (which would be simple enough to add).

I have no problem adding that, it is the hook for the additional checks, and would improve readability. But destroies the golang 1 compatibility.

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.

A "struct{}" is comparable, but only to itself, not to any other type, including any other "struct{}" try compiling:

package main

import (
    "fmt"
)

type s struct{}
type t struct{}

func main() {
    var a s
    var b t
    if a == b {
        fmt.Printf("Hello, playground %v %v\n", a, b)
    }
}
it fails to do so: a and b have different types because of named type equivalence.

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.

This type inference may well be added here too. But for typical container uses I doubt this is helpful at all. When thinking about functional libraries it makes more sense. I did not include this aspect to keep things simple. Type inference would require in my proposal same marking that you want to have it. Otherwise you might break code relying on polymorphic use of "interface" types.

But I would love to see a IDE or some separate tool to make the type inference and add the proper type bindings to the import statements automatically. This could also help you to magically transform go1 programms to go2.

Remember: in my proposol the polymorphic use of interface types and are way closer.

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).

good remark, I will fix this, you must drop them in the monomorphic transformation.

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.

ok. but the compiler tells you where the now superflous typ cast are, or the above tool could easily fix this both ways.

The harder stuff is the "[]interface{}" quirk of golang. Here a monomorphic implementation allows you to drop a nasty copy of a parameter slice with concrete types.

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.

In my profesional live I am busy writing C++. completely disagree. No "local template usage" anywhere. The templates are always in header files.
But sometimes there are specialisations within the same header, but this needed only to solve C++ quirks.
And I agree: for the discussion it is the biggest impediment, in normal every day coding I doubt it is a problem at all.

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.

Agree with that, but the solution suggested in the proposal would nicely fit here too, because it adds an new form of "interface{}" type definition, for this purpose. Which may be used to define named parameters as well. So the "Comparable" of the golang draft may well be used in my proposal unchanged.
But I wanted to keep things simple and concentrate on the important pieces, which is the syntax without need for a new brackets discussion.

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.

I know. I am way too late. Sorry for stealing your time. I only have one strong argument: it is a way simpler solution.

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.

Point 6 may be solved easily, see above, I think point 5 the breaks the neck here.
Personally I think in praxis generic collections are the far more important aspect than functional libraries containing "Min" and "Max" functions.
And your writing was all about collections too.

Thank a lot for Your suggestions!

Martin Leiser

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Gas-PrmfknY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHT%3DkMEEqx4UTS6qojHawrNOfON72JdAckUHfzfduh3Ag%40mail.gmail.com.

[Brian Candler]

(Back to the OP's blog post)

This is an interesting read, thank you!

One question: did you consider using data []*T in the buffer?  If so, what made you discount it?  It seems a natural way to indicate "empty" slots in the slice.

Another way would be a separate slice of bools for marking whether each slot was empty.  Or have a single slice of a struct which contains both a T and a bool:

https://go2goplay.golang.org/p/jg3pEY8PwEn

[Ben Burkert]

Thanks for reading!

> One question: did you consider using data []*T in the buffer?  If so,

> what made you discount it?  It seems a natural way to indicate "empty"

> slots in the slice.

I didn't consider using a []*T at the outset because I assumed that the

Buffer type would still need to be exposed to the user as part of the

old "type safe" API. Had that been the case, then creating a pubsub for

pointers to a struct (e.g. PubSub[*S]) would mean the user would have to

manipulate a buffer of pointers to pointers to structs (e.g.

Buffer[**S]), which isn't great. Now that I know the Buffer type doesn't

need to be exported, in the future (when generics are ready) I will

likely change the internal layout of the buffer and cell to incorporate

the empty marker, like in your example with the slot type.