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”.
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.
The `strings.Compare`[1] function is used to establish ordering, in the spec sense. You'd think they would name it "Order".
Similarly, the popular go-cmp[2] library provides `Equal` for equality, instead of `Compare`.
[1]: https://godoc.org/strings#Compare [2]: https://github.com/google/go-cmp
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
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.