On Tue, Jun 24, 2014 at 6:06 PM, Vadim Chugunov <[email protected]> wrote: > > 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. >> >> > 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. >
I'm hoping for illumination on that last point from someone who understands the type system. If, say, u32w subtypes u32, then a u32w collection would not be assignable to/from a u32 collection. It's the covariant/contravariant mess. [Mathematicians don't pick understandable names like "visitor pattern."] -- Jerry
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
