Negative numbers in types like-uint

[tredoe]

The compiler should show a warning message when is used a negative number into a like-uint type

let n: u8 = -1;
println!("{}", n); // => 255

[jdm]

Probably related to #2438.

[recrack]

Should this be done in typeck, or is it best done in lint?

[Aatch]

Nominating for production-ready.

[msullivan]

Yeah, I agree with that nomination.

[cmr]

This should really be a lint I think

[graydon]

Relative of #4220 and #5551 so probably milestone #1.

[graydon]

accepted for well-defined milestone

[pcwalton]

Nominating because I believe we decided to not do this for negative numbers and the warning is already implemented for positive numbers. I think this can be closed.

[cmr]

I think we should have a lint for bare -1 when it infers to an unsigned type, but -1u should be allowed. Generally I think the more-obvious construction !0, !0 - 1 etc should be used instead of negative literals.

[fhahn]

Could this lint be combined with the type_overflow lint? The message of that lint ("literal out of range for its type") would fit in my opinion and and it shouldn't be too hard to extend the code of this lint.

[cmr]

I think at this point we've gone whole-hog on accepting that not warning on this is a feature. Nominating for closure.

[pnkfelix]

Lints are not a language backwards-compatibility issue.

Recategorizing as P-low, not 1.0 milestone.

[mbrubeck]

PistonDevelopers/image#305 is an example of a real-world bug that would have been caught by this warning. That bug involved code like std::iter::range_step(len, 0, -1) where len is unsigned.

[nagisa]

Relevant internals discussion

[pnkfelix]

see #23945; we're going further than a lint and moving to a feature-gate at this point.

The goals are two-fold:

1. Removing unary-negation on unsigned integers does seem more consistent with our current overflow story, and
2. if the community does strongly want -expr to work on unsigned integers, then this is a way to force the community to tell us. (Perhaps using stronger language than we might otherwise want, we shall see...)

[SiegeLord]

Code like this compiles and runs without error in stable rustc today:

let a = -1; // 'a' gets inferred to u32, but the code compiles without error
let b: u32 = a;

Is the intention to stop that code from compiling or issue a runtime error?

[nagisa]

Yes, although that would be somewhat of a breaking change.
On Jul 13, 2015 9:08 AM, "SiegeLord" notifications@github.com wrote:

Code like this compiles and runs without error in stable rustc today:

let a = -1; // A gets inferred to u32, but the code compiles without error
let b: u32 = a;

Is the intention to stop that code from compiling or issue a runtime error?

—
Reply to this email directly or view it on GitHub
#5477 (comment).

[pnkfelix]

The intention was to force examples like above comment to be feature-gated (and thus you'd have to opt-in to be able to write them). But it seems like the feature-gating code in #23945 did not catch this case (or it has regressed since then, which seems less likely to me...)

[rnestler]

@SiegeLord

let a = -1; // 'a' gets inferred to u32, but the code compiles without error
let b: u32 = a;

Gives a warning in stable and fails to compile in nightly for me on play.rust-lang.org

[steveklabnik]

Yes, I would consider this fixed. The example is now fixed, it's behind a feature gate, and so when/if the gate is stabilized or removed, this will end up being discussed, so I think all of the concerns in this ticket are taken care of. Let me know if that's wrong!