consider removing the fallback to int for integer inference

[thestinger]

I find it really easy to accidentally end up using int. It can be inferred as uint based on a function call, but if you delete a line of code you're back to int and possibly a bug. I don't think it's that much pain to tag one of them with i.

If #4169 is implemented, different strategies for overflow (expand to big integer, wrap, trap with a condition) can just be implemented as first-class library types. Haskell has a fallback to a big integer, but at least that's much less likely to cause a bug.

[pcwalton]

I think this might be pretty annoying; e.g. println(1.to_str());

[pcwalton]

Nominated for backwards-compatible milestone, but I suggest WONTFIX

[thestinger]

I agree it would be annoying if you actually want int, but I think it would prevent a lot of mistakes. There are many counters that should really be unsigned, but Rust defaults them to int.

Especially if we end up with generic integers like Haskell, this would make overflow checked integers and big integers as first-class as the built-ins (excluding constant expressions).

[graydon]

accepted for backwards-compatible milestone

[catamorphism]

Visiting for triage.

[brson]

cc #4704

[nikomatsakis]

I personally favor not guessing, or at least trying it

[1fish2]

There are many counters that should really be unsigned ...

Using unsigned values for such purposes can cause bugs, e.g. when a loop counts down past 0. This is why the Google C++ Style Guide http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Integer_Types#Integer_Types says:

... do not use unsigned types to say a number will never be negative. Instead, use assertions for this.
... Consider:

for (unsigned int i = foo.Length()-1; i >= 0; --i) ...

[huonw]

@1fish2 note that our range and range_step iterators handle counting down to zero like that correctly, even for unsigned types, so the advice for Rust is "writing your own counter loops is bad", not "using unsigned types is bad". (Admittedly there are other situations in which one should prefer a signed type to an unsigned type to avoid bugs, but I'm sure that loops are the most common one in C/C++.)

for i in range(0u, 10).invert() { print!("{} ", i) }

prints

9 8 7 6 5 4 3 2 1 0 

[1fish2]

Agreed (esp. about writing your own loops). Perhaps a better way to put it is doing unsigned math doesn't save you from thinking about negative values, it just underflows them to large values.

Does range() always iterate downwards? I don't see any doc on that, e.g. http://static.rust-lang.org/doc/master/std/iter/fn.range.html

[thestinger]

@1fish2: he was missing the invert call in the original snippet

[thestinger]

@1fish2: well, I think we can agree that a pointer-sized integer with wrapping on overflow is a bad default for high-level application code whether or not we agree on the value of unsigned integers at API boundaries :)

[denispir]

I do agree int as default type is a bad point. My preferred solution is the standard type to be either uint or int depending on whether a literal value is signed or not. Meaning, one would write let n = +1; to get a signed int.

The solution of adding an explicit type suffix 'u' or 'i' (with or without precision of size) is also good and acceptable in my view. Then, seems an assignment without type name nor suffix should be a compile error?

[emberian]

@denispir we already have said type suffixes.

I really want generic numeric literals. Neither int or uint are the right choice, usually, and when they are, type inference can take care of it (only need to specify the type once, somewhere).

[brson]

Nominating for closing. I don't see a lot of momentum to change this and it's a huge change. Does anybody think we can or will?