4 ms·

Link to the current draft: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/r

Link to the current draft: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...

saghm 6y ago
I'm usually a bit of a skeptic when it comes to Go, but this proposal surprised me; for the most part, or seems like this is exactly what I would want if I were a Go programmer. Being able to define both unbounded generic parameters and parameters bounded by interfaces is key, and while from skimming I'm not sure if it allows giving multiple interfaces as a bound, in practice this shouldn't be a huge issue due to how Go's interfaces are implicitly implemented (which would allow you to define a new interface that's the union of all the other interfaces you want to require, and all the types that implement all of them will automatically implement the new one). Interestingly, the proposal also defines what is essentially a union type interface, which I think is something that Go definitely could use. Although there are a couple of minor warts (e.g. not being able to have generic methods) and the syntax is not what I'd personally pick, overall I'm pretty impressed.
- djur 6y ago
  As someone who doesn't enjoy Go but is increasingly having to deal with it at work, I'm very happy with it.
coder543 6y ago
This is the new code branch: https://go.googlesource.com/go/+/refs/heads/dev.go2go https://go.googlesource.com/go/+/refs/heads/dev.go2go I can't find the actual code review for this. It seems to be hidden/private still? This was the previous code review: https://go-review.googlesource.com/c/go/+/187317 https://go-review.googlesource.com/c/go/+/187317 The comment at the end is where I got the link to the new branch, but as an outsider, I don't have any good way to ask where the new code review is, so I'm leaving this comment here in hopes that a googler will see it and point me in the right direction. Based on a link that's on the new branch's page, it might be CL 771577, but it says I don't have permission to view it, so I'm not sure.
- ianlancetaylor 6y ago
  There isn't a code review for the changes on the dev.go2go branch (though you could construct one using git diff). The dev.go2go branch will not be merged into the main Go development tree. The branch exists mainly to support the translation tool, which is for experimenting with. Any work that flows into the main Go development will go through the code review process as usual.
Someone 6y ago
“A type parameter with the comparable constraint accepts as a type argument any comparable type. It permits the use of == and != with values of that type parameter” I think that’s an unfortunate choice. Quite a few other languages use the term equatable for that, and have comparable for types that have =, ≤ and similar defined. Using comparable here closes the door for adding that later. I also find it unfortunate that they chose type SignedInteger interface { type int, int8, int16, int32, int64 } as that means other libraries cannot extend the set of types satisfying the constraint. One couldn’t, for example, have one’s biginteger class reuse a generic gcd or lcm function.
- coder543 6y ago
  Languages have been known to use “Ordered”, “Orderable”, or “Ord” for what you’re calling “comparable”. Rust and Haskell are both languages that fit this criteria. The design draft refers to “constraints.Ordered”, so they’re definitely thinking about having both “comparable” and “constraints.Ordered”. Although, for consistency with “comparable”, I think it should be called “constraints.Orderable”.
  - Someone 6y ago
    That’s true, but both rust (https://doc.rust-lang.org/beta/std/cmp/trait.Eq.html https://doc.rust-lang.org/beta/std/cmp/trait.Eq.html) and Haskell (https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Eq.html#t:Eq https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-...) use eq or similar for what this proposal calls comparable, as do C# (IEquatable), java (through Object.equals), and Swift (Equatable)
    - coder543 6y ago
      Sure, but as someone else already pointed out, “comparable” is an established Go term that refers to “==“ and “!=“ only, and “ordered” refers to the other comparison operators. My point was that “comparable” is not universally used in place of the “Ordered” term that the Go team is using, as you were seemingly implying. Ordered is a perfectly fine term for it. You said: > Using comparable here closes the door for adding that later. But the door is not closed in any way. It’s just called “constraints.Ordered”, which is perfectly reasonable.

Link to the current draft: https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...

saghm 6y ago

I'm usually a bit of a skeptic when it comes to Go, but this proposal surprised me; for the most part, or seems like this is exactly what I would want if I were a Go programmer. Being able to define both unbounded generic parameters and parameters bounded by interfaces is key, and while from skimming I'm not sure if it allows giving multiple interfaces as a bound, in practice this shouldn't be a huge issue due to how Go's interfaces are implicitly implemented (which would allow you to define a new interface that's the union of all the other interfaces you want to require, and all the types that implement all of them will automatically implement the new one). Interestingly, the proposal also defines what is essentially a union type interface, which I think is something that Go definitely could use. Although there are a couple of minor warts (e.g. not being able to have generic methods) and the syntax is not what I'd personally pick, overall I'm pretty impressed.

djur 6y ago
As someone who doesn't enjoy Go but is increasingly having to deal with it at work, I'm very happy with it.

coder543 6y ago

This is the new code branch: https://go.googlesource.com/go/+/refs/heads/dev.go2go https://go.googlesource.com/go/+/refs/heads/dev.go2go I can't find the actual code review for this. It seems to be hidden/private still? This was the previous code review: https://go-review.googlesource.com/c/go/+/187317 https://go-review.googlesource.com/c/go/+/187317 The comment at the end is where I got the link to the new branch, but as an outsider, I don't have any good way to ask where the new code review is, so I'm leaving this comment here in hopes that a googler will see it and point me in the right direction. Based on a link that's on the new branch's page, it might be CL 771577, but it says I don't have permission to view it, so I'm not sure.

ianlancetaylor 6y ago
There isn't a code review for the changes on the dev.go2go branch (though you could construct one using git diff). The dev.go2go branch will not be merged into the main Go development tree. The branch exists mainly to support the translation tool, which is for experimenting with. Any work that flows into the main Go development will go through the code review process as usual.

Someone 6y ago

“A type parameter with the comparable constraint accepts as a type argument any comparable type. It permits the use of == and != with values of that type parameter” I think that’s an unfortunate choice. Quite a few other languages use the term equatable for that, and have comparable for types that have =, ≤ and similar defined. Using comparable here closes the door for adding that later. I also find it unfortunate that they chose type SignedInteger interface { type int, int8, int16, int32, int64 } as that means other libraries cannot extend the set of types satisfying the constraint. One couldn’t, for example, have one’s biginteger class reuse a generic gcd or lcm function.

coder543 6y ago
Languages have been known to use “Ordered”, “Orderable”, or “Ord” for what you’re calling “comparable”. Rust and Haskell are both languages that fit this criteria. The design draft refers to “constraints.Ordered”, so they’re definitely thinking about having both “comparable” and “constraints.Ordered”. Although, for consistency with “comparable”, I think it should be called “constraints.Orderable”.
- Someone 6y ago
  That’s true, but both rust (https://doc.rust-lang.org/beta/std/cmp/trait.Eq.html https://doc.rust-lang.org/beta/std/cmp/trait.Eq.html) and Haskell (https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Eq.html#t:Eq https://hackage.haskell.org/package/base-4.12.0.0/docs/Data-...) use eq or similar for what this proposal calls comparable, as do C# (IEquatable), java (through Object.equals), and Swift (Equatable)
  - coder543 6y ago
    Sure, but as someone else already pointed out, “comparable” is an established Go term that refers to “==“ and “!=“ only, and “ordered” refers to the other comparison operators. My point was that “comparable” is not universally used in place of the “Ordered” term that the Go team is using, as you were seemingly implying. Ordered is a perfectly fine term for it. You said: > Using comparable here closes the door for adding that later. But the door is not closed in any way. It’s just called “constraints.Ordered”, which is perfectly reasonable.