On Tue, Jun 24, 2014 at 11:58 AM, Daniel Micay <[email protected]> wrote:
> That's why I support adding attributes but turning wrapping on overflow > on and off for a scope. You can indicate whether wrapping is considered > correct in that scope, meaning you either expect it to wrap or you have > audited it (just as you would an `unsafe` block) and determined that it > can not overflow. This doesn't introduce implementation defined > behaviour or new language dialects via compiler flags. > > Rust has been consistently opposed to adding compiler switches changing > the meaning of the code. The metadata belongs *in the code* itself, and > you are free to flip wrapping on/off for whatever reason in the code > itself. I agree except there are 3 cases even if the compiler treats two of them the same. Whatever order Gábor listed them, there's: (1) Wraparound is correct here, e.g. in a hash function. This is important information to programmers, debuggers, analysis tools, and testing tools even if the compiler treats it identically with #2. (2) [Default] Wraparound would be incorrect but don't check at runtime to save the performance costs. This includes the audited case -- Tools should still consider overflow here bad. (What's the distinction between "bug" and "error"?) Even we audited this code, maybe we goofed in our audit and maybe later code changes invalidated some of our assumptions. (3) Wraparound is incorrect and do check at runtime. Hopefully the language would not require precise exceptions for these integer overflow checks and future development work would test techniques like AIR. On ergonomics: * It sounds good to specify #2 and #3 with annotations so the choice can be made and changed on a whole scope, and yes, so the information is in the source code for all programmers and tools to see. Q: Is there a practical way to scope it larger than a function? Q: Could testing tools temporarily change the annotation's behavior to make #[unchecked] act as #[checked]? Q: Could debugging tools temporarily change the annotation's behavior into a precise exception to aid debugging? * #1 is separate -- that code won't change to/from #2 or #3. An annotation sounds reasonable although wraparound operators sound better since they're more visible and not accidentally changed when editing annotations. -- Jerry
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
