clarify extreme operator behaviour

[Gankra]

This is just clarifying things which were agreed on in various places but poorly specified.

rendered draft

[eddyb]

Maybe division and remainder by 0 are "nonsensical", but INT_MIN / -1 is an overflow, the same way -INT_MIN is (which isn't caught, not even in a debug build).

[nagisa]

rust-lang/rust#24500 and rust-lang/rust#23154 and rust-lang/rust#22020 all seem to involve unary negation checking for overflow, but in practice this seems to be not working indeed in the context of const-eval.

[eddyb]

-std::i32::MIN does give a const-eval error, but let m = std::i32::MIN; -m doesn't (so there's no runtime checking).

[nagisa]

Seems to work for me.

[eddyb]

Oops, I used playbot - does it run in release mode?

[17:13] <eddyb> playbot: let x = std::i32::MIN; -x
[17:13] [Notice] -playbot to #rust-internals- -2147483648

[nikomatsakis]

Regarding -INT_MIN and INT_MIN/-1 -- for whatever reason, division had code to check and panic, but multiplication did two's complement wrapping. We have preserved that behavior, afaik, inconsistent or not, and hence these edits correctly describe the current situation.

[Gankra]

Clarified.

[glaebhoerl]

As @bill-myers originally pointed out here INT_MIN % -1 is mathematically well-defined to be 0.

[nikomatsakis]

Hear ye, hear ye. This RFC is entering final comment period.

[nikomatsakis]

@glaebhoerl true. I guess we could consider altering the behavior, but I think this RFC is basically aiming at documenting existing behavior, and that particular result is long-standing.

[glaebhoerl]

@nikomatsakis Then shall I open a separate issue to keep track of that possibility?

[nikomatsakis]

On Sat, Sep 05, 2015 at 01:53:14AM -0700, Gábor Lehel wrote:

@nikomatsakis Then shall I open a separate issue to keep track of that possibility?

Sure.

[nikomatsakis]

Huzzah! The language design team has decided to accept this RFC.