This is a delayed response to an earlier post in this thread by @mgeisler.
[pardon the rambling prologue]
As I’ve posted before (here and here), my initial foray into Rust led me to sketch an RFC to add lexemes for wrapping_add/sub/mul and rotate_left/right operators and their assign variants. Because rustc is open source and I’ve considerable experience with compiler internals, I downloaded a copy of the rustc source and worked out the code changes needed to add those operator lexemes and their corresponding traits to rustc. (I did not attempt to develop all the needed documentation changes.)
Once I’d concluded that such operator lexeme additions were feasible, I investigated the impact that they would have on both the rustc source and on the source of the “crypto” category crates on crates.io (since the latter are presumably the heaviest users of wrapping arithmetic). As I reported in the first-cited reference, in that corpus only 5% of the add and subtract operators were of the wrapping variety, which strongly suggested that do nothing was a viable choice.
That conclusion led naturally to consideration of what can be considered best practices if the language is not changed. Investigation determined that other authors had already found an approach that is in many ways superior to the “extend the language” alternative.
From this experience I concluded that any RFC for a language change should include both
- statistics on how widely the change would improve a sizable representative corpus of existing source code, and
- discussion of “best practice” alternatives if the change is not made.