On Tue, Jun 24, 2014 at 5:48 PM, Jerry Morrison <jhm...@gmail.com> wrote:
> 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? > Literal type could be inferred, just like it is inferred now for regular ints. > 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 <danielmi...@gmail.com> > 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. > > Easy: don't use normal ints in the API, Cast to wrapping ints when needed. I don't expect the slice scenario to come up often, but if it does, these slice types can be transmuted into each other.
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
