A tale of two's complement

[glaebhoerl]

@petrochenkov

If the intent is to prohibit optimizations, be formal about it and don't use "unspecified values", use another terminology.

I agree with the sentiment; prohibiting optimizations is a goal, and a precise definition is a means of achieving that goal. As of when I wrote the RFC, I didn't know what a good definition would be, which is why it doesn't contain one. (And I'm still not completely sure!) But many in this thread (discussing undef, etc.) seem to have been unaware of the goal itself.

@petrochenkov

Rust already postulates 2's complement everywhere else (e.g. signed shifts), so you can freely use "no value or 2's complement wrap-around".

I wasn't fully aware of this. However, my problem with this definition is still that it could encourage people to use #[overflow_checks(off)] as a way to request two's complement semantics, which I rather dislike. (I'm also not sure whether or not it would be too strict to allow for things like delayed exceptions, AIR, etc... I'm not really familiar with those.)

@petrochenkov

Is unary minus allowed on unsigned numbers?

This is a good question. Generally, the philosophy is that implementations are allowed and encouraged to diagnose inevitable over- or underflows at compile time, and also to insert checks at runtime depending on user-provided flags/attributes. Specifically, -1u should be completely equivalent to 0u - 1u. So just from the general principle, this means that -1u could end up as any of a compile-time warning, a runtime panic, or neither.

However, as negation of unsigned values is specifically known to always underflow (except in the case of 0, when it does nothing), it would likely be more sensible to just disallow the operation entirely, as you imply.

@petrochenkov

It would be very sad to lose -1 as "the maximum value of unsigned type", but acceptable, I guess.

I'm not sure that it would be sad at all. Bounded::max_value() or u32::MAX are much more obvious. (Hopefully once we get associated constants, these two can be a single thing.)

@petrochenkov

Does -1i as uint panic or not? Does 0xFFu8 as i8 panic or not?

Yes and yes, presuming that checks are enabled. The issue of conversions was mentioned briefly in the RFC. For two's complement wrapping conversions between integer types, a safe Transmute/Coercible/etc. trait could be used if we had one (not yet), or the unsafe transmute() if all else fails. For others, e.g. float to integer, I'm not sure what a good design would be.

@petrochenkov

After thinking about these two questions, a new set of symbolic operators with wrapping behaviour looks more and more tempting..

Does this impact the issue of conversions at all? Otherwise, symbolic operators would just be syntactic sugar over .wrapping_add(), etc. calls, and I'm not sure they're used commonly enough to be worthwhile.

[petrochenkov]

@glaebhoerl

I'm also not sure whether or not it would be too strict to allow for things like delayed exceptions, AIR, etc...

Doesn't AIR give the same results as modulo arithmetic for basic operations (if it gives them at all)? I don't know myself, need to investigate.

@glaebhoerl

Does this impact the issue of conversions at all? Otherwise, symbolic operators would just be syntactic sugar over .wrapping_add(), etc. calls, and I'm not sure they're used commonly enough to be worthwhile.

No, it doesn't. I definitely don't propose these operators for 1.0 and could omit this paragraph entirely.

I agree with everything else, thanks for the clarifications.