I mostly agree, though for #1, I think that new int types would be more appropriate. A set of special operators seems like an overkill for a relatively infrequently used functionality. Annotations are too broad (what if I need to do both wrapping and non-wrapping calculations in the same scope?).
On Tue, Jun 24, 2014 at 5:03 PM, Jerry Morrison <[email protected]> wrote: > > 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 > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
