Amend overflow RFC to alter semantics of as; make wrapping methods inherent methods

[nikomatsakis]

As the subject says.

Some prior discussion: http://internals.rust-lang.org/t/on-casts-and-checked-overflow/1710/

[glaebhoerl]

What's the motivation for moving from WrappingOps to inherent methods apart from "we now can"? How do we keep Wrapping<T> (heretofore defined in terms of WrappingOps) working?

[zkamsler]

/s/wilil/will/

[nikomatsakis]

@glaebhoerl ah, well, my motivation is primarily that we might want to organize the ops trait differently. For example, if we added +% operators or whatever, then they would probably each want their own trait to be more analogous to Add, Sub, and friends.

[bill-myers]

If this is being changed, how about the idea of adding new types whose operations wrap instead? (e.g. m8, m16, m32, m64)

That would be the mathematically and conceptually correct approach.

Also this would allow to disable the iX/uX integer types for programs that want to avoid the risk of overflow and only want to use closed integer types.

[aturon]

This was discussed briefly at today's meeting and at great length in internals. This is largely a decision about syntax/naming (since this unchecked/bitwise conversion needs to be provided one way or another), and the general consensus is that as indicating semi-dangerous coercions -- i.e., the status quo -- is a fine solution.

[pnkfelix]

@bill-myers BTW there is supposed to be some future work on making more ergonomic wrapping arithmetic operations. (But this particular amendment to the arithmetic overflow RFC is not addressing that problem.)

[tbu-]

@aturon Implementing safe conversion as "future work" sounds very dangerous. People will use as as a generic conversion unless an ergonomic alternative is added.

[nikomatsakis]

@bill-myers I'd suggest you comment on this thread http://internals.rust-lang.org/t/ergonomics-of-wrapping-operations/1756. In particular, DaGenix's comment makes a strong case against this approach of adding wrapping types in the third paragraph that I'd like see a refutal of.

UPDATE: To clarify, I meant "DaGenix persuaded me that modular types are a bad idea", so basically to change my mind, I'd (personally) like to see those arguments refuted.

[aidancully]

@nikomatsakis I'm sorry to say, but I find that comment a bit frustrating: I tried to refute the argument that "modular types are a bad idea" here, and now it seems that my response was, I'm not sure how else to interpret this, entirely ignored.

To retread that argument here, I argue that modular types are not right the right fit for crypto (which is what I think DaGenix showed), but are often right in other domains (I personally do a lot of work with time values that wrap, and where using checked arithmetic would be a bug. Working with wrapping time values is extremely common when working with embedded RTOSes.). Type systems are for ensuring that only valid operations are attempted against particular types of data, and if we can say that a particular type of data should only use wrapping operations, the type system should help out by disallowing non-wrapping operations. Similarly, we might also define Checked<T> in addition to Wrapping<T> if we want to make explicit that only checked operations make sense for a particular data type, and disallow wrapping_add etc.

The thing that really stops wrapping types from being useful is that current Rust doesn't allow easy conversions between derived types of newtypes. For example, it should be possible to convert between Vec<i32> and Vec<Wrapping<i32>> without using the scary big transmute stick. I believe this is a general issue that can and should be resolved. (update: RFC 949 seems like it would address the big ergonomics issue with wrapping types.)

[tbu-]

@aidancully If you want a quick fix for your code, you could make an extension trait for the integer types which adds the wrapping_* functions.

[aidancully]

@tbu- Thanks, I will probably pursue that strategy. I think the issue, though, is whether libcore should be responsible for providing a standard means of working with wrapping arithmetic exclusively, or whether it should be left to external crate authors to define their own (likely mutually-incompatible) types with specifically-selected overflow semantics. And then there would still be the issue that you can't easily cast T<i32> <=> U<Wrapping<i32>> without using transmute and throwing a lot of protection out the window.

[nikomatsakis]

@aidancully

Sorry if I seemed dismissive; I'm certainly open to persuasion that we should have better support for modular types (and your examples are helpful in that regard). In any case, my intention with that comment was not so much to shutdown the argument, as to redirect that conversation from this RFC and onto the ergonomics thread, which I think is a more suitable place for it. In any case, if we are to grow better support for modulo-integer-types, I think I'd prefer to see it done by addressing the ergonomic limitations of Wrapped<T> rather than extending the core set of integer types in the language. (Among other things, this would give more flexibility, such as types are "modulo N" for arbitrary N, and not necessarily just limited to machine integers.)