On 24/06/14 01:55 AM, Jerry Morrison wrote: > > > On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay <[email protected] > <mailto:[email protected]>> wrote: > > On 24/06/14 01:17 AM, Jerry Morrison wrote: > > > > Does `checked { }` mean all functions within that scope use > > checked-integer arithmetic? This sounds great to me. > > It would only apply to local operations. It's not possible to alter the > behaviour of functions in general because of crates. It would also be > incorrect if they required wrapping semantics. > > > One detail: There should be a way to explicitly specify > > wraparound-arithmetic, e.g. wraparound-arithmetic operators. Lint > would > > never complain about that. > > I think the scope-based solution would probably be cleaner in that case: > > #[checked] > fn foo() { ... } > > #[unchecked] > fn bar() { #[checked] { ... } } > > The lint would warn for operations in a scope without an explicit > decision one way or the other. You could even put `#[checked]` at module > / crate level and override it in inner scopes. > > I think that's as a sane solution, as opposed to introducing dialects > with compiler switches which I really dislike. > > > Attributes do seem saner than compiler switches. > > Intentional-wraparound arithmetic is different than > unchecked-for-speed-and-lint-could-complain, and probably only applies > to fixed sized, unsigned integers. Would you use wraparound operators > like &+ for those?
Well, perhaps a better naming convention is `#[wrapping(no)]` (with checks) and `#[wrapping(yes)]`. I don't really like the idea of having language support for a no-op convention.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
