# Remove error "expected f64 found integral variable" (allow numeric literals without \`.\` where it's never ambiguous) **URL:** \ **Category:** ideas (deprecated)\ **Created:** [January 31, 2015, 9:50pm UTC](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503 "2015-01-31T21:50:40Z")\ **Posts on this page:** 7\ **Page:** 2
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [February 3, 2015, 4:51pm UTC](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503/21 "2015-02-03T16:51:55Z")
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. ---
**Author:** ![wackywendell](https://avatars.discourse-cdn.com/v4/letter/w/c4cdca/32.png) [@wackywendell](https://internals.rust-lang.org/u/wackywendell)\ **Post date:** [February 3, 2015, 5:09pm UTC](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503/22 "2015-02-03T17:09:53Z")
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… ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [February 4, 2015, 1:39pm UTC](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503/23 "2015-02-04T13:39:25Z")
I am very nervous about this change. Here is an example that makes me nervous: ```rust 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](http://discuss.rust-lang.org/t/implicit-widening-polymorphic-indexing-and-similar-ideas/) and the dangers involved there. ---
**Author:** ![troplin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/troplin/32/1182_2.png) [@troplin](https://internals.rust-lang.org/u/troplin)\ **Post date:** [February 4, 2015, 10:25pm UTC](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503/24 "2015-02-04T22:25:03Z")
> [@nikomatsakis](#): > > 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. ---
**Author:** ![DanielKeep](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/danielkeep/32/1332_2.png) [@DanielKeep](https://internals.rust-lang.org/u/DanielKeep)\ **Post date:** [February 5, 2015, 6:13am UTC](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503/25 "2015-02-05T06:13:54Z")
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? ---
**Author:** ![troplin](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/troplin/32/1182_2.png) [@troplin](https://internals.rust-lang.org/u/troplin)\ **Post date:** [February 5, 2015, 5:37pm UTC](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503/26 "2015-02-05T17:37:42Z")
> [@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`. 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. > [@DanielKeep](#): > > 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. ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [March 25, 2019, 8:23am UTC](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503/27 "2019-03-25T08:23:48Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed. [Previous page](https://internals.rust-lang.org/t/remove-error-expected-f64-found-integral-variable-allow-numeric-literals-without-where-its-never-ambiguous/1503.md?page=1)