> > Hypothetically, if Go introduced generics where you couldn't write
> > min/max but included min/max builtins, what's the next smallest
> > example where operators are necessary?
>
> // Contains returns whether v is in the slice s.
> func Contains(type T)(s []T, v T) bool {
> for _, x := range s {
> if x == v {
> return true
> }
> }
> return false
> }
That's true. You can have this with interfaces as type constraints
with https://github.com/golang/go/issues/27481 however. That's the
minimally-necessary operator since comparing things is going to come
up more than anything else and == is the only operator not limited to
a small family of types.
There's still the problem with Equals vs ==, but that's a fundamental problem.
> > I'd be happy with generics if I needed to sometimes write a little bit
> > of code to do a few things but didn't have to write a tremendous
> > amount of code to do most things. That seems like a good trade off,
> > even if it's not necessarily a popular one.
>
> But you can already do that, though, using interfaces. Before we
> added sort.Slice, people complained quite a bit about sort.Interface,
> and that only required three lines. Heck, people still complain that
> we have sort.Ints but not sort.Int32s.
In some cases like that. You can't have generic homogeneous type-safe
containers without some form of generics. That was the sort of thing I
was referring to: If I had to write a wrapper type with a Less method
to use a generic B-Tree that's not a big deal compared with writing an
entire B-Tree specialized to a certain type or having to wrap the
whole api to make it type safe.
Very few of the things I've wanted to do with generic require anything
other than at most == and convertibility. The lack of < would be
annoying at times but it's trivial to work around.
> > You could also write a min/max that operates on types with a Less
> > method, like you could under the various just-interfaces schemes.
> >
> > But you can't write one that works on both.
>
> Yes. Though I'm not clear on whether people want that. I think we
> need experience with real code here.
>
> If experience show us that this is important, my current guess is that
> the path forward here for Go is type adaptors, in which we say
> something like "if T implements contract C1, then you can
> automatically add this wrapper type and the wrapper type will
> implement contract C2." But I think that is clearly a problem for
> later.
I forget where, but at some point I mentioned there could be equals(x,
y) and less(x, y) builtins that
- use x.Less(y) if it exists
- if not, use x < y
- if neither fail to compile.
(or Equals/== respectively)
Then you can use them in the contract and generic bodies. That would
only work with the contract proposal and not any of the interface
ones.
--
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.
For more options, visit https://groups.google.com/d/optout.
