RFC for removing integer inference fallback

[brson]

Rust infers primitive integer types, but when it can't find a solution it currently defaults to int. This is often seen as a potential subtle footgun. This RFC describes how to remove the feature, per rust-lang/rust#6023.

[SiegeLord]

Perhaps default type parameters could be dual-purposed to provide a fallback type for this case (see rust-lang/rust#13702). I.e. the signature of range would become:

pub fn range<A: Add<A, A> + PartialOrd + Clone + One = uint>(start: A, stop: A) -> Range<A>

although it wasn't clear to me if the original issue was motivated by this very function defaulting to int too often.

[alexcrichton]

It would be nice to have statistics on the amount of the changes required (ascriptions necessary) to code after these tweaks were implemented. This is a difficult statistic to gather, however, and I would think that it would fall out of the implementation regardless.

[bstrie]

Do you really mean "cast" here?

[brson]

No, I meant 'provide type hints'. Will change.

[bstrie]

I think I'm for this. In ancient Rust this was a useful hack, but nowadays it's probably too magical. And if we decide that we want the old behavior again later, adding the integral fallback back in would be a backwards-compatible change, yeah?

[thestinger]

@bstrie: Yeah, adding a fallback would be backwards compatible. In the case of floats, I think f64 is actually a sane default. Floats are insane to start with, so it doesn't really matter :P.

[pcwalton]

@alexcrichton I believe @nikomatsakis has already gathered these statistics.

[brendanzab]

I'm in favor of this. I have been bitten by it before too.

[Kimundi]

I'm also in favor of this.

[bill-myers]

Shouldn't enum discriminants be the smallest type that allows to represent them all? (with preference for either signed or unsigned, not sure)

Or maybe we could introduce integer range types, and then it could be the smallest range covering them all, with no ambiguity.

[brson]

I believe that is going to be the rule. Enums are the smallest type (probably not specced as such), unless using #[repr(...)].

[bstrie]

@thestinger, I'm fine with the f64 fallback for floats because at least it's falling back to a type whose size doesn't vary per-platform. In the past I've floated the idea of changing our integral fallback from int to i32, but that may very well be a worse idea than just removing the fallback altogether. :)

[nikomatsakis]

@alexcrichton I did gather such statistics in the original issue.

[alexcrichton]

@nikomatsakis, @pcwalton ah of course, I forgot!

For those wondering, the analysis is here: https://gist.github.com/nikomatsakis/11179747

[brson]

@alexcrichton Updated per https://github.com/rust-lang/rust/wiki/Meeting-weekly-2014-06-17#rfc-pr-115-removing-int-inference-httpsgithubcomrust-langrfcspull115-

[alexcrichton]

Merging per the discussion that @brson has linked to.

[alexchandel]

Too bad I arrived late to the party. Feel free to show me the light, but this feels like a significant backwards step in the elegance of Rust. When I type "let a = 4", I expect a to be: signed because I haven't specified a signedness; and native-word sized because I haven't specified a size. And similarly for let a = 1.0. The very fact that Rust has type inference suggests all of this to me as a user.

[thestinger]

Integer literals are generic, the type of x in let x = 5; is determined based on the usage of x. For example, in let x = 5; x += 2u32;, x is a u32. You should only use a pointer-size integer if it's actually what you need. You can't use a fixed-size integer without thinking about the bounds, so a pointer-size integer is a bad fallback.