Skip to content

Generic boolean operators #1008

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Generic boolean operators #1008

wants to merge 2 commits into from

Conversation

ryanhiebert
Copy link

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.

Rendered

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`.
MyModel.my_field == 42 & MyModel.my_other_field > 17
```

It is my opinion that operators are _significantly_ more readable and parsable than operators in this context, and that the return value not being a boolean is apparent in the context. That being said, if allowing the boolean operators to return non-boolean values was not acceptable, then this would probably be the next best option for my use-case.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@milibopp
Copy link

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
Copy link

daboross commented Apr 8, 2015

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 nikomatsakis self-assigned this Apr 9, 2015
@nikomatsakis
Copy link
Contributor

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!

@Centril Centril added A-primitive Primitive types related proposals & ideas A-operator Operators related proposals. A-compare Proposals relating to comparisons. labels Nov 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-compare Proposals relating to comparisons. A-operator Operators related proposals. A-primitive Primitive types related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants