Hacker News Reader

Comment by jandrese | Hacker News Reader

Is it a bug if the compiler thinks that maybe the value could grow too large to fit in an integer so it promotes it to a floating point type. But then you compare it to a value that is converted out of a string of ASCII digits and the comparison is off by 1 because 4 != 3.99999999996 and this causes your code to iterate one additional loop which doesn't cause an immediate problem except about 1 in every 256 times it causes a boundary condition where the next packet will have a corrupt first byte?

Technically the compiler technically did nothing wrong, but you are still left with a head scratcher because all of the logic seems sound and yet it produces occasional garbage.

View on HN

Scala's compiler used to widen prematurely and apply implicit conversions similarly to what you described.

Scala 3 doesn't do that [1]. The new inference algorithm will, however, prefer a generic method over the same named method without a generic argument in scope when no typing hints are present in the source code when there are two possible matches for an inference completion. This can then cause problems when the generic expects some kind of given parameter:

    def foo: String = ...
    def foo[A:SomeRequiredThing]:A = ...

    //in some other place
    foo shouldBe("hello") // foo[String](using SomeRequiredThing[String])
                          // gets preferentially selected by the scala 3
                          // inference algorithm, which can lead to surprising
                          // though not "incorrect" results [also 1]

[1] https://www.youtube.com/watch?v=lMvOykNQ4zs

What compiler does that? What you're describing sounds like a weirdly designed type system, not a compiler that implements it.

That said, this is an example of the compiler being wrong.

If a value is changed to a data representation with different comparison semantics, and later compared to a different value of a different representation, it means the original optimization (hand wave over the definition of that) was unsound in the first place. AOT compilers would classify this as a bug that needs to be fixed imminently, and JIT compilers that do this kind of thing use something called dynamic deoptimization to remove the change once its been invalidated.

Yes, promoting an integer to a float is 100% wrong and should result in a compilation error (if you dislike overflows) or an integer overflow (if you dislike compilation errors) or even a promotion to a BigInt type (if you dislike both other alternatives). Promotion to a float is always wrong.

> Technically the compiler technically did nothing wrong

I don't know a single language where integers are "promoted" to floats when they get large; certainly no statically typed language. You could argue JavaScript does this, but it's neither compiled nor does it actually have integers. So yes, if a compiler did that it would be a bug.

type inference isn't magic. It would absolutely be a bug for the compiler to change the type of a variable from an int to a float because it thinks there will be overflow.

Reply on news.ycombinator.com