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.
friendly reminder that if an object is stuck in a wall or such and it's vibrating erratically, it will usually be building up a lot of momentum because the physics engine is constantly applying a depenetration force. do not interact with it; you will not survive the impact and even if you do you will likely escape the solar system within a dozen ticks or so.