Generic boolean operators

[ryanhiebert]

Boolean operators, such as ==, !=, <, etc, are currently defined by std::cmp::{Eq,Ord}, and require that they return bool. It would be a useful generalization to allow them to return alternative types, in similar form to std::ops.

Previous discussions on the Rust Reddit, Rust Internals Discourse, and IRC.

• http://www.reddit.com/r/rust/comments/2xu8rn/boolean_operators_to_not_return_bools/
• http://internals.rust-lang.org/t/pre-rfc-boolean-operators-that-dont-return-bool/1684

Rendered

[aepsil0n]

[…] operators are significantly more readable and parsable than methods […]

[aepsil0n]

In principle, I find that a good idea. It's also somewhat problematic that the standard library mixes operator definition with the concept of equivalence from a mathematical point of view. However, it is almost certainly too late for this change.

[daboross]

I would be for keeping + and - supporting other return types, but not comparing operators like ==, < and >. Adding / subtracting / multiplying it makes sense mathematically/grammatically to allow different return types, because it doesn't make much sense to add a Point to a Point and get an integer. But for equality/comparing operators, it makes perfect sense for every single type to have the same kind of result from comparing.

The only time you wouldn't want this is if you were trying to form some sort of calculation to perform later, or to create some sort of custom closure. For something you would execute later in the same program, like a filter, it would be better just to make a closure. For SQL/database stuff, just use a macro that turns >/</== into calling methods on your own trait.

I wouldn't want to pay the cost of not knowing what ==/>/< will do, just to allow for some lazy evaluation or SQL using >/</==. It is much more valuable to have each operator do what you expect, evaluating now, than allow for forming other structures.

[nikomatsakis]

This proposal is a subset of a previously proposed (and postponed) alternative. Therefore, I'm marking this as postponed under #420. Thanks for the suggestion!