Change type deduction rules to allow integer literals to be deduced as floats.

[minno726]

This is an issue that came up in IRC today. It seemed strange to me that a program like let num: f32 = 1; wouldn't pass the type checking rules while let num = 1f32; does, so I'm proposing this change to make it work.

[lilyball]

I'm cautiously in favor of this. Do you have any information on how other statically-typed, compiled, type-inferencing languages behave in this regard? Offhand, Swift seems to allow 1 to be inferred as a floating-point value, but I don't have any other appropriate language compilers installed at the moment to check (e.g. Haskell).

[lilyball]

I think not. 2e60 is a valid floating-point literal with an f64 value of 2000000000000000000000064884426862042680048006680208002800648, but it doesn't produce a warning.

[dhardy]

+1. Integers aren't so special and 3. is IMHO ugly.

As to coercion, if the compiler can pick up something which is clearly not doing what it looks like it is (e.g. 2^60 + 1 as f32), then a warning/error makes sense. But in the general case there are plenty of similar errors which are impossible to catch, so my opinion is not to worry to much.

[lucy]

Haskell allows this. OCaml does not. SML seems to not allow it either.

[Kimundi]

+1 from me, any integer literal is possibly a valid float literal already, and any problems about different sizes/ranges already exist anyway and would probably need a more general solution (Like parsing number literals as bigints and then doing range checks on them)

[bharrisau]

Would it suffice for the majority of cases to have values less than 65536 interpreted as 'maybe float'. I know a f32 effectively has 24 bits, but I think the major motivator for this is smaller literals anyway?

[SiegeLord]

Just coded some mathematical code, and really wished for this RFC to have already been implemented. This is probably the biggest ergonomic issue for me in Rust. In other languages (C family) this is implemented via implicit casting, but in Rust this has a chance of being perfectly type safe.

[netvl]

+1. I'm also trying to write some math programs in Rust and, for example, writing cplx!(1.0, 1.0) for 1+1i instead of cplx!(1, 1) is really annoying.

[vks]

I think this makes a lot of sense. Code where the intention is very clear does not work currently:

let x: f64 = 1;

Might it make sense that 1 desugars to One::one()?

[emberian]

I also really really want this. It makes working with floats more verbose and painful than necessary, and is easy to forget.

[emberian]

@vks I don't think it makes sense for 1 to desugar to One::one(). It'd make One a language item and we shouldn't go down the path of overloadable literals just yet.

[vks]

@cmr I agree, however overloadable literals would be very sweet.

[bluss]

@cmr Not to mention that only solves the issue for the 1 literal, and at least 2^64 - 2 literals remain.

@netvl Until it is resolved, know that you can write cplx!(1., 1.), &[1., 2., 3.] etc.

[vks]

@bluss You could also make those overloadable.

[retep998]

@bluss I'm sure I don't have to point out how ugly a sequence of ., looks.

I would so love to have this. As for the precision issue, just have a lint that fires whenever a literal is outside the range that a float can represent exactly, and another off by default lint for when an integer literal is used as a float at all.

[brson]

Although a number of people are in favor of this, we don't feel an urgent need to do this now, amongst all the other pending features. Furthermore there are some concerns about unexpected interactions with the default integer type, where people expecting operations to infer to floats actually infer to ints. We're going to postpone this and reconsider it later.

Discussion. Tracking

[ticki]

Are there any plans for reopening this issue?