3 ms·

If Range doesn't require PardialOrd, I'm not sure I know what Range is at all...

fluffything 6y ago
I don't even know what PartialOrd and PartialEq even are, mathematically speaking... The docs about these feel written by someone who knew that "some API like this" would be a good idea, but that somehow never managed to flesh out what these traits should semantically imply. Which is kind of dumb, given that there was _excellent_ prior art about this when Rust was created (Elements of Programming, From mathematics to generic programming, the C++ standard library and the dozen papers about operator<=>, ...). And that's one of the things I dislike more about rust. The way to overload operators, like +, or <, uses trait names, like Add or PartialOrd, which suggest that these operators have certain semantics (particularly when using Add in where clauses), but in practice they lack any semantic meaning and are just syntactic things. Which is why, e.g., the standard library implements "Add" for strings. That doesn't mean that it implements "Addition" for strings, but rather that it overloads the Plus operator. And in the String case it does so to implement "Concatenation". Which is IMO super dumb, because they could have just fixed this by naming the `Add` trait `Plus` instead, which is what languages that do the same thing, like C++, already do (`std::plus`, `operator+`, ....). You could argue that using `+` to implement concatenation is "bad", but it is way less worse than using "Addition" to implement concatenation, which is what Rust ends up requiring everybody to do because that's just how you overload the `+` operation.
- xondono 6y ago
  > I don't even know what PartialOrd and PartialEq even are, mathematically speaking... They are binary relations, just some that are more "niche" than the more common ones. PartialEq actually has a link to it's mathematical definition on the docs [0]. [0]:https://en.wikipedia.org/wiki/Partial_equivalence_relation https://en.wikipedia.org/wiki/Partial_equivalence_relation
  - fluffything 6y ago
    > They are binary relations, Thanks for making my point: this API provides _a_ binary relation is IMO useless. There are millions of binary relations that one could implement for a type, and often many that make sense implementing for a particular type, and that this API doesn't support (e.g. there are both strict partial order and total orders for float in the IEEE standard; this API however implements none). For this to be useful, the docs would at least need to say what can one assume about the partial order implemented by PartialOrd (is it strict? is it non-strict? something else?), and ideally have a solid ordering hierarchy so that APIs and algorithms can pick what makes sense to them, instead of having to assume the lowest-possible denominator imaginable, which results in, e.g., it not making sense to implement ordering for floats in the standard library, even though to be IEEE compliant it would actually need to do that.
LukaD 6y ago
It does indeed require PartialOrd and the author has already fixed the mistake. But I wonder why PartialOrd is implemented for ().
- GlitchMr 6y ago
  This is because tuples like `(T, U)` implement `PartialOrd` - this is actually useful. If you are going to implement `PartialOrd` for tuples, it makes sense to implement it for 0-tuple too.

I don't even know what PartialOrd and PartialEq even are, mathematically speaking... The docs about these feel written by someone who knew that "some API like this" would be a good idea, but that somehow never managed to flesh out what these traits should semantically imply. Which is kind of dumb, given that there was _excellent_ prior art about this when Rust was created (Elements of Programming, From mathematics to generic programming, the C++ standard library and the dozen papers about operator<=>, ...). And that's one of the things I dislike more about rust. The way to overload operators, like +, or <, uses trait names, like Add or PartialOrd, which suggest that these operators have certain semantics (particularly when using Add in where clauses), but in practice they lack any semantic meaning and are just syntactic things. Which is why, e.g., the standard library implements "Add" for strings. That doesn't mean that it implements "Addition" for strings, but rather that it overloads the Plus operator. And in the String case it does so to implement "Concatenation". Which is IMO super dumb, because they could have just fixed this by naming the `Add` trait `Plus` instead, which is what languages that do the same thing, like C++, already do (`std::plus`, `operator+`, ....). You could argue that using `+` to implement concatenation is "bad", but it is way less worse than using "Addition" to implement concatenation, which is what Rust ends up requiring everybody to do because that's just how you overload the `+` operation.

xondono 6y ago
> I don't even know what PartialOrd and PartialEq even are, mathematically speaking... They are binary relations, just some that are more "niche" than the more common ones. PartialEq actually has a link to it's mathematical definition on the docs [0]. [0]:https://en.wikipedia.org/wiki/Partial_equivalence_relation https://en.wikipedia.org/wiki/Partial_equivalence_relation
- fluffything 6y ago
  > They are binary relations, Thanks for making my point: this API provides _a_ binary relation is IMO useless. There are millions of binary relations that one could implement for a type, and often many that make sense implementing for a particular type, and that this API doesn't support (e.g. there are both strict partial order and total orders for float in the IEEE standard; this API however implements none). For this to be useful, the docs would at least need to say what can one assume about the partial order implemented by PartialOrd (is it strict? is it non-strict? something else?), and ideally have a solid ordering hierarchy so that APIs and algorithms can pick what makes sense to them, instead of having to assume the lowest-possible denominator imaginable, which results in, e.g., it not making sense to implement ordering for floats in the standard library, even though to be IEEE compliant it would actually need to do that.

LukaD 6y ago

It does indeed require PartialOrd and the author has already fixed the mistake. But I wonder why PartialOrd is implemented for ().

GlitchMr 6y ago
This is because tuples like `(T, U)` implement `PartialOrd` - this is actually useful. If you are going to implement `PartialOrd` for tuples, it makes sense to implement it for 0-tuple too.