@Ian, I have been thinking and I’ve come up with a possible solution to
yours and some other problems. I’d love to hear your thoughts on it. Note,
that this is a very fresh idea.
I’m addressing two problems here:
1.
Inability to do Min/Max and other generic numeric functions.
2.
There are a few kinds of generic parameters, but the kind is always
implicit. This can be a problem because changing the body of a function can
result in a backward-incompatible change, even when the signature remains
the same.
Here are the ideas (also described in the proposal now, in the section
called ‘Further ideas’).
The kind of a generic parameters is currently completely implicit. Some
annotation could be added. One possible syntax could be like this:
1. gen n for generic array lengths.
2. gen T for arbitrary types (convertible to interface{}).
3. gen eq T for equalable types (comparable with == and usable as map
keys).
4. gen num T for numeric types (with operators like +, -, <, …).
Array lengths and arbitrary types can have the same notation because it’s
always possible to distinguish them by context. Alternatively, they could
be distinguished by capitalization (lower-case for array lengths,
upper-case for types).
Syntax-wise, eq and num would not be keywords on their own. Rather, gen eq
and gen num would be two-word keywords.
The syntax is rather ad-hoc, I admit. It’s a very fresh idea, completely
open to refinement. However, since there are only four cases, an ad-hoc
syntax may actually be the right choice.
It’s also easily extensible with new possible “contracts”, but I’d
generally advise against that.
The addition of the num restriction would actually enable many cool things.
First, the Min/Max functions:
func Min(x, y gen num T) T {
if x < y {
return x
}
return y
}
It would also be useful for generic math types, like vector and matrices.
The matrix example above uses float64, but it could be generalized to all
numeric types.
As an example, let’s take a look at a possible implementation of a 2D
vector type:
type Vec2(T) struct {
X, Y T
}
There are no restrictions specified in the type definition. This is because
it’s methods and functions that require restrictions, not the types
themselves. For example, this String method requires no restrictions:
func (u Vec2(gen T)) String() string {
return fmt.Sprintf("(%v, %v)", u.X, u.Y)
}
This Eq method requires the types to be comparable with ==:
func (u Vec2(gen eq T)) Eq(v Vec2(T)) bool {
return u.X == v.X && u.Y == v.Y
}
But, this Add method requires the types to be numeric:
func (u Vec2(gen num T)) Add(v Vec2(T)) Vec2(T) {
return Vec2(T){u.X+v.X, u.Y+v.Y}
}
Consequently, Vec2([]float64) would only have the String method,
Vec2(string) would have the Eq method in addition, and Vec2(float64),
Vec2(int32), and so on, would have all the methods.
Yes, the idea basically is to introduce two "contracts" into the system.
However, there's no ability to create own contracts and the syntax is very
concise and non-disruptive. I believe this would really cover the vast
majority of use-cases.
pi 31. 5. 2019 o 14:05 <fge...@gmail.com> napísal(a):
> On 5/31/19, Nick Keets <nick.ke...@gmail.com> wrote:
> ...
> > This proposal is very interesting and seems to fit nicely into Go, with
> > minimal disruption. And speaking personally, it would cover 99% of my
> needs
> > for generics (I'm not that interested in Min/Max, but writing functions
> to
> > get map keys gets old fast).
> Interesting, could you please share the problems where the usual
> iterating idiom is not good enough?
>
> --
> 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/CA%2Bctqro9o-RAa6QRVCEQ%2BPu_tre%2BCtJQZaP4LbBTB_6LQntWyg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAO6k0usrzSrh1j-xboqtxh8jJCz0eRDpfvTggfgi-0%3D10XhNoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
