3 ms·
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 criter
by 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 agoThat’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 agoSure, 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.
- joppy 6y agoIn my opinion, ordered or orderable is a better name than comparable for types implementing (<=). It evokes more of a "totally ordered" vibe than just saying "comparable", which is what we actually want in these types (in order to sort them and so on).