Yeah. And would programmers also have to convert each literal, like in the Java-ish hashCode() example:
result = (wint) 31 * result + (wint) areaCode; because adding a non-wraparound integer and a wraparound integer is ambiguous? Hey, it's "just" 5 more arithmetic operators. (A building architect once said, "'Just' is a 4-letter word.") On Tue, Jun 24, 2014 at 5:41 PM, Daniel Micay <[email protected]> wrote: > On 24/06/14 08:39 PM, Vadim Chugunov wrote: > > 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?). > > Introducing new types would make the language more painful to use, and > it would be difficult to determine the correct types to use at API > boundaries. It would be a large backwards compatibility hazard among > other issues, and would introduce performance overhead due to issues > like `&[u32]` and `&[u32c]` being different types. > > -- Jerry
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
