in Rust, the + and - operators have the same precedence, and the .. operator is way lower, and will
As such, you might expect expressions involving them all to look basically identical if you sub out + for -. The observant among you might also immediately sus out from this description that this has to do with unary -.
fn f() {
{ 1 + 2 + .. + 3 + 4 }
{ 1 - 2 - .. - 3 - 4 }
}
// becomes
fn f() {
{ 1 + 2 + (..) + 3 + 4 }
{ 1 - 2 - (..((-3) - 4)) }
}
In the first expression, it is acting as an expression (..), and only in the second one does it exist as a unary operator. So, this isn't violating any operator precedence. Only the second one is even potentially ambiguous, and how it's handled feels quite intuitive, even if it caught me off guard.
in fact, .. is a prefix operator, and a binary operator, and a postfix operator, and an expression all on its own.
fn f() {
let x = (..((..)..(..)))..;
// x has type RangeFrom<RangeTo<Range<RangeFull>>>
}
But i did lie, it's not really an operator at all:
fn f() {
0 == 0 == 0 ;
0 .. 0 .. 0 ;
}error: comparison operators cannot be chained
--> src/lib.rs:3:7
|
3 | 0 == 0 == 0 ;
| ^^ ^^
|
help: split the comparison into two
|
3 | 0 == 0 && 0 == 0 ;
| ++++
error: expected one of `.`, `;`, `?`, `}`, or an operator, found `..`
--> src/lib.rs:4:12
|
4 | 0 .. 0 .. 0 ;
| ^^ expected one of `.`, `;`, `?`, `}`, or an operator
Parsing of ranges is fucking weird.
Conversation
Notices
-
Embed this notice
sodiboo (sodiboo@gaysex.cloud)'s status on Monday, 30-Jun-2025 13:27:23 JST sodiboo
- Jesse 🇫🇷 likes this.