<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay <span dir="ltr"><<a href="mailto:danielmicay@gmail.com" target="_blank">danielmicay@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 24/06/14 01:17 AM, Jerry Morrison wrote:<br>

><br>
> Does `checked { }` mean all functions within that scope use<br>
> checked-integer arithmetic? This sounds great to me.<br>
<br>
</div>It would only apply to local operations. It's not possible to alter the<br>
behaviour of functions in general because of crates. It would also be<br>
incorrect if they required wrapping semantics.<br>
<div class=""><br>
> One detail: There should be a way to explicitly specify<br>
> wraparound-arithmetic, e.g. wraparound-arithmetic operators. Lint would<br>
> never complain about that.<br>
<br>
</div>I think the scope-based solution would probably be cleaner in that case:<br>
<br>
#[checked]<br>
fn foo() { ... }<br>
<br>
#[unchecked]<br>
fn bar() { #[checked] { ... }  }<br>
<br>
The lint would warn for operations in a scope without an explicit<br>
decision one way or the other. You could even put `#[checked]` at module<br>
/ crate level and override it in inner scopes.<br>
<br>
I think that's as a sane solution, as opposed to introducing dialects<br>
with compiler switches which I really dislike.<br>
</blockquote></div><div class="gmail_extra"><br></div>Attributes do seem saner than compiler switches.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-- <br>   Jerry
</div></div>