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
<https://github.com/golang/go/issues/43651#issuecomment-772744198>.
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
On Sun, Feb 7, 2021 at 9:20 PM Martin Leiser <leiser.1...@gmail.com
<mailto: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
<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/
<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
<mailto: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 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
<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+unsubscr...@googlegroups.com
<mailto: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
<https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHT%3DkMEEqx4UTS6qojHawrNOfON72JdAckUHfzfduh3Ag%40mail.gmail.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/3bd1da2e-091e-34ef-bec0-9631424dc089%40gmail.com.
