Numeric widening and weak conformance

Currently we’re doing what scalac is doing WRT to this issue. Example:

List(1, 2.3) // res: List[Double]

from a user standpoint, this should in a stricter language have been inferred as List[Int | Double]. In scalac they have a flag for this Ywarn-numeric-widen. Which is not yet implemented in Dotty.

If we choose not to make inference for this type of construct stricter, then we should definitely implement the Ywarn-numeric-widen-flag.

[sjrd]

Could we simply remove weak conformance from the language altogether? Seems like a thing inherited from Java that few like anyway.

[lihaoyi]

@odersky what about the following:

object Foo{
  def main(args: Array[String]): Unit = {
    val list = List(1.2, 92233720368547751L, 4)
    val long =           92233720368547751L
    println(list)
    println(list(1))
    println(list(1).getClass)
    println(list(1).toLong)

    println(long)
    println(list(1).toLong == long)
    
  }
}

sbt: [info] Running Foo
List(1.2, 9.2233720368547744E16, 4.0)
9.2233720368547744E16
double
92233720368547744
92233720368547751
false

(https://scastie.scala-lang.org/btdDoZBcRNqJRWm12VMXWA)

Here, we have the same literal resulting in two different, unequal values, due to widening/conformance/whatever. There are no type annotations here, so I don’t expect any implicits to kick in: if anything, I’d expect to get a List[Any] containing the mix of Longs and Doubles that I wrote in the source code. But I don’t and so 92233720368547751L ends up being two different values.

Surely the same literal resulting in different values is a real problem, and that’s not just pedantic busywork?

I don’t really care what the solution is, whether it’s union types or intersection types or inferring Any or whatever. I just don’t want my numbers mysteriously, irreversibly losing precision despite there being no explicit conversions in sight