4 ms·
I would prefer not to see that happen, I'm fine with as and the safer options as they are currently. It would be a big job to update all the code in the wild wh
by eloff 5y ago
I would prefer not to see that happen, I'm fine with as and the safer options as they are currently. It would be a big job to update all the code in the wild when you want to move to the newer edition.
- wizzwizz4 5y agoYou don't need to do that. Rust editions are fully backwards-compatible, since they can depend on code from different editions.
- eloff 5y agoI'm aware of that, which is why I specified when you want to move to the newer edition.
- tialaramex 5y agoI don't see it as a big job. Am I wrong? Imagine there's a suitable narrow::<type>() function introduced which has the same consequence, always narrowing, if your data was too wide it may drop important stuff on the floor, and narrow() just says that's too bad. Rust 2030 can introduce narrow::<type>(), warn for narrowing as usage and then Rust 2035 can error for as. The Rust 2030 -> 2035 conversion software can consume code that does { x as y } and write { x.narrow::<y>() } instead. This code is not better but it's still working in Rust 2035 and this explicit narrow() function is less tempting for new programmers than as IMO.
- scns 5y agoYes, BUT the correct thing to do would be more tedious to write that way.
- cdirkx 5y agoIsn't this something that could be done automatically by rustfix?