This is a rather broadly-impacting change, so I'd say yes.
(It's very different from, say, just adding a method to Vec.)
This is the biggest reason. See
rust-lang:master ← VFLashM:master
I think the major unknown here is still how to do this without huge inference br… eakage. To use an example from above, in `x == 1_000_000_000_000` how can the rules still use the type information from `x` to know what the literal should be? Defaulting the literal to `i32` and changing behaviour due to truncation despite compiling is clearly unacceptable, worse even than compilation failure.
The main back-and-forth is essentially whether this is useful. On one side is appreciation that this has intuitive behaviour and makes the safe-and-correct thing easy, since it's much easier to do this wrongly than correctly today, and comparison can be done without pitfalls like surprising overflows. Simultaneously there's criticism that this hides mistakes elsewhere (that are compilation errors today), makes the machine code emitted by the operators less obvious, leads Rust towards C-style fuzziness about types, and that the correct thing to do is to change types elsewhere so that there isn't a type mismatch.
I wish we could do it, since not having it means that people are incentivised to do their comparisons incorrectly. But like with indexing , we can't right now.
(Maybe once we get chalk?)
1 Like