On Mon, Aug 3, 2020 at 5:10 PM 'Axel Wagner' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
>
> IMO the discussion about this is purely based on the idea of type-lists which
> exists purely so as to support operators on type-parameters. And personally I
> feel a better way to solve this solution would be to just drop that from the
> design. IMO, the utility of this isn't really worth the cost. Especially
> given that there's no way to write a function to work with *either* methods
> *or* operators, so the actual practical utility is pretty small. Arguably you
> need two copies of any function working with - one for "primitel types" using
> operators and one for "composite types" using methods. That seems… inelegant
> to say the least and I'm not convinced that it's better than to require
> people to add a method to "primitive types" to use them in generic code. And
> IMO a more orthogonal solution to allowing use with "primitive types" would
> be some form of operator overloading or endowing predeclared types with
> suitable methods - either would allow us to actually write generic code that
> could work with both primitive and composite types, without needing us to
> introduce a separate way to specify constraints.
>
> That being said, I know that the people driving the design consider being
> able to write generic code using operators non-optional, so I know that this
> likely won't happen. But I do think it's important to allow using interfaces
> as constraints and I do think that any benefit of separating the concepts
> would probably vanish, as long as you allow that - being able to have both
> seems to me the prototypical compromise, in that it combines the downside of
> both ideas. So, personally, I still strongly believe that re-using interfaces
> is the right design.
Yes, I think that the ability to write generics using operators is not
optional. As I've said before, there are some functions that must be
possible to write using any plausible generics mechanism. One of them
is the Min function that returns the smaller of two values of some
ordered type. If we can't write that trivial function, our generics
mechanism is not usable for practical code.
Defining operators for every operation that applies to a builtin type
in Go is surprisingly hard. I think we wind up needing something like
40 different methods. That is not a simple approach.
I agree that it would be inelegant to have to write every function
twice, once with operators and once with methods. But it's not yet
entirely clear to me that that is what will happen. I suspect that in
Go it will often be more natural to pass in an appropriate function
rather than to require a method. Admittedly sort.Interface works
differently, but that is because it additionally requires Swap and Len
methods that are not required in generic code. A generic sort in Go
seems more likely to use a comparison function than to require a
method, and similarly for other typical examples. It would be
interesting to hear about counter-examples where methods are more
appropriate.
Anyhow, if I'm right, that reduces the problem to: is there a simple
way to get an appropriate function for a primitive type. And, of
course, there is:
func Less(type T constraints.Ordered)(a, b T) bool { return a < b }
Now I can call sort with primitives.Less(int32) or whatever. And I
think we are going to be able to define type inference such that in
common cases it will work to pass simply primitives.Less.
And of course for those who really like methods we could even have
package methods
type lesser(type T) interface { Less(T) bool }
func Less(type T lesser)(a, b T) bool { return a.Less(b) }
and now you pass methods.Less to the function in question.
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/CAOyqgcXuxWhpzJVp_dpgD_4QVYWe--9Gf_QJ0H%2BLpP6k%2B3q6Lg%40mail.gmail.com.
