Remove error "expected f64 found integral variable" (allow numeric literals without `.` where it's never ambiguous)

[kornel]

I mean unambiguous for the compiler. It can’t make the program use a wrong type, so I don’t think it can lead to a mistake.

Ambiguity for human reader is a different thing, and in your example indeed it’s not immediately obvious to a human reader what type 1 has, but neither would 1.0, because it’s actually f32 and not f64.

To me requiring .0 on floating point type literals is akin to requiring explicit + on unsigned types just so you know right there that it’s a u type, and not i type.

It’s allowed to use 1 where you don’t immediately see if its actual type is i8 or usize or anything between, but you can write 1u8 if you want to make it obvious. And I think similarly you should be able to use 0 in f32/f64 context, but can write 1.0 or 1f32 if you feel this context needs to be more explicit.

[wackywendell]

Well, it sounds to me like this is now a matter of taste. In general, the Rust team has not allowed the compiler to infer everything it possibly could everywhere, because sometimes explicitness is preferred for the sake of the reader, even when the compiler doesn’t need it; this happens in several places with & and &mut, for example. I can see that reason pretty well: asking a coder to write 1.0 instead of 1 is not asking much, but may well help the reader out. Is that “help” to the reader worth the “inconvenience” to the coder? That to me is where its a matter of taste…

[nikomatsakis]

I am very nervous about this change. Here is an example that makes me nervous:

fn foo(x: f32) { ... }

foo(3/2)

Today, that generates an error. Depending on precisely how we coded this up, this change might cause it to be accepted, and result in 1.5. I am not convinced this is good. The fact that integer division truncates is fine, I think, but the more we blur the lines between integer and floating point, the more dangerous it becomes.

This seems pretty related to the discussion on implicit widening and the dangers involved there.

[troplin]

The fact that integer division truncates is fine, I think, but the more we blur the lines between integer and floating point, the more dangerous it becomes.

IMO the real problem is, that floating point division and integer division are two different operations but using the same operator. If they would use different operators, this would not be a problem at all.

[DanielKeep]

The problem with that is you end up with an argument for not having operator overloading at all, and every type has its own version of the arithmetic operators. After all, u8+u8 is not the same thing as i32+i32, is not the same thing as f32+f32.

Having used Python, I’m sympathetic to the idea that “truncating division” is in some way a different operation to “real division”. The question is: what would you use for the operator (// is kinda already used for something else), and is there any point in talking about this at this late stage, when it would break all code using division on integers?

[troplin]

The problem with that is you end up with an argument for not having operator overloading at all, and every type has its own version of the arithmetic operators. After all, u8+u8 is not the same thing as i32+i32, is not the same thing as f32+f32.

I’d argue that they are semantically the same (except for FP precision issues) where wrapping is not intended (the majority of the cases).

And IMO wrapping integers should be a separate type from normal integers anyway. If wrapping is intended, implicit conversion is probably wrong in almost all cases. Mixed expression with other types make no sense and should be forbidden.

is there any point in talking about this at this late stage, when it would break all code using division on integers?

Compared with other languages, it’s still very early stage but yeah, probably not.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.