Assigning integral literals to floating-point types should warn when losing precision

[kynthus]

Compiler version

3.0.0-M3

Minimized example

val f1: Float  = 123456789            // Loses precision without saying anything. (Int => Float)
val d1: Double = 1234567890123456789L // Same as above. (Long => Double or Long => Float)

val  n: Int    = 123
val  l: Long   = 123456L

val f2: Float  = n // Assignment from variable is warning. (Int => Float)
val d2: Double = l // Same as above. (Long => Double or Long => Float)

Output

No warning when assigning integral literals.
However, I always get a warning when assigning from variables such as Int and Long.

Starting scala3 REPL...
Scala compiler version 3.0.0-M3 -- Copyright 2002-2020, LAMP/EPFL
scala> val f1: Float  = 123456789            // Loses precision without saying anything. (Int => Float)
val f1: Float = 1.23456792E8

scala> val d1: Double = 1234567890123456789L // Same as above. (Long => Double or Long => Float)
val d1: Double = 1.23456789012345677E18

scala> val  n: Int    = 123
     | val  l: Long   = 123456L
val n: Int = 123
val l: Long = 123456

scala> val f2: Float  = n // Assignment from variable is warning. (Int => Float)
1 |val f2: Float  = n
  |                 ^
  |method int2float in object Int is deprecated since 2.13.1: Implicit conversion from Int to Float is dangerous because it loses precision. Write `.toFloat` instead.
val f2: Float = 123.0

scala> val d2: Double = l // Same as above. (Long => Double or Long => Float)
1 |val d2: Double = l
  |                 ^
  |method long2double in object Long is deprecated since 2.13.1: Implicit conversion from Long to Double is dangerous because it loses precision. Write `.toDouble` instead.
val d2: Double = 123456.0

Expectation

I expected to be warned even with integral literal assignments.

It seems that there was a hot discussion about widening conversion of value types.

• Precision loss due to numeric conversions #2289
• Numeric widening and weak conformance #2451
• New specification for dropped weak conformance. #5358
• Tweak and implement weak conformance replacement #5371

On the other hand, it is strange that the warning does not occur only in the case of literals.
Using Scala 2.13.2 to 2.13.4, Doing the same will give you a warning.

Welcome to Scala 2.13.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_202).
Type in expressions for evaluation. Or try :help.

scala> val f1: Float  = 123456789
                        ^
       warning: Widening conversion from Int to Float is deprecated because it loses precision. Write `.toFloat` instead.
val f1: Float = 1.23456792E8

scala> val d1: Double = 1234567890123456789L
                        ^
       warning: Widening conversion from Long to Double is deprecated because it loses precision. Write `.toDouble` instead.
val d1: Double = 1.23456789012345677E18

I understand that unlike Scala 2, Scala 3 doesn't have the concept of widening conversion.
Isn't checking integral literals realistic?

[odersky]

One problem here is that we rely on the 2.13.1 library. I believe that it went too far in deprecating int2float. The essence of Floats and Doubles is that they lose precision! Nobody will give you a warning when you write

val x: Float = ...
val y: Float = x * x

even though that might lose precision as well. I should have been consulted when this was put in. /cc @lrytz

This does not say that we could not do a better job checking literals and flagging ones that are too big to be represented accurately. What would be a good test for that?

[SethTisue]

The Scala 2 PRs in question were: scala/scala#7405 (original submission), scala/scala#8679 (re-submission), scala/scala#8757 (followup)

[odersky]

Thanks for the history, @SethTisue! I still think it's wrong. Here's another argument why:

val x: Float = 12345
val y: Float = x * x

vs

val x: Int = 12345
val y: Float = x * x

One gives a warning, the other doesn't. Yet they produce the same imprecise result.

[lrytz]

To me, there's a difference between imprecise operations when working within floats / doubles and lossy implicit conversions.

Programmers working with floating point numers are (hoepfully) aware of imprecise operations. But lossy conversions should always be explicit, they happen too easily accidentally.

The fact that val x: Float = 12345 doesn't warn is because it's not lossy, for literals the warning is limited to when the conversion is actually imprecise, which makes sense to me.

[som-snytt]

The Scala 2 PRs are pre-pandemic, from before the beginning of the world as we know it. I see I commented on the PR that was not merged that the warning corresponds to (lack of) harmonization:

Starting scala3 REPL...
scala> Seq(1, 3.14f)
val res0: Seq[Float] = List(1.0, 3.14)

scala> Seq(123456789, 3.14f)
val res1: Seq[AnyVal] = List(123456789, 3.14)

and therefore scala 2 warns

scala> Seq(123456789, 3.14f)
           ^
       warning: Widening conversion from Int to Float is deprecated because it loses precision. Write `.toFloat` instead.
val res0: Seq[Float] = List(1.23456792E8, 3.14)

If Scala 3 had -Xlint, the inference of AnyVal would also warn.

It's also worth saying again that some people think deprecation implies removal, whereas it may mean simply, "that is bad practice."

[aumann]

To me, there's a difference between imprecise operations when working within floats / doubles and lossy implicit conversions.

Programmers working with floating point numers are (hoepfully) aware of imprecise operations. But lossy conversions should always be explicit, they happen too easily accidentally.

The fact that val x: Float = 12345 doesn't warn is because it's not lossy, for literals the warning is limited to when the conversion is actually imprecise, which makes sense to me.

I agree. Another example (from a current Java project): We changed the type of a (rather pervasive) field called "time" from double to long, precisely because we need a slightly different encoding for absolute precision now.
This leads to lot of code of the form:
double oldCode = reader.getTime() // since refactoring: long getTime()

The current Scala behavior would warn everywhere this appears, which would be such a huge help for the refactoring.