<div dir="ltr">Yeah. And would programmers also have to convert each literal, like in the Java-ish hashCode() example:<br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="font-family:'courier new',monospace">result = (wint) 31 * result + (wint) areaCode;</span> </div>
</blockquote><div><div>because adding a non-wraparound integer and a wraparound integer is ambiguous?</div></div><div><br></div><div>Hey, it's "just" 5 more arithmetic operators. (A building architect once said, "'Just' is a 4-letter word.")</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 5:41 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 24/06/14 08:39 PM, Vadim Chugunov wrote:<br>
> I mostly agree, though  for #1, I think that new int types would be more<br>
> appropriate.   A set of special operators seems like an overkill for a<br>
> relatively infrequently used functionality.  Annotations are too broad<br>
> (what if I need to do both wrapping and non-wrapping calculations in the<br>
> same scope?).<br>
<br>
</div>Introducing new types would make the language more painful to use, and<br>
it would be difficult to determine the correct types to use at API<br>
boundaries. It would be a large backwards compatibility hazard among<br>
other issues, and would introduce performance overhead due to issues<br>
like `&[u32]` and `&[u32c]` being different types.<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>   Jerry
</div>