Sdk: Double.infinity should not exist

[creativecreatorormaybenot]

Problem

The problem I feel is that n / 0 does not throw an exception. Only n ~/ 0 throws an IntegerDivisionByZeroException. This is frankly completely unintuitive.

What even is the use of double.infinity anyway? I think that it should be removed as I assume that there is no real use case that requires double.infinity and could not be solved better.

Motivation

I just encountered a problem that was incredibly hard to detect because my app was stuck in a loop (which I know now) and I did not even consider the possibility of Infinity being used somewhere, which made any attempts of finding the issue harder.

[lrhn]

The Dart double type follows the IEEE-754 standard for floating point numbers, which requires positive and negative infinity, positive and negative zero, and not-a-number as values.

There are no current plans to change this behavior, which is also shared by languages like Java, JavaScript and C#.
The one place where Dart stands out compared to Java and C# is that division of two integers can create a double. In both Java and C#, the int / int operations is different from the int / double operation due to overloading. Dart does not have overloading, and it has a common supertype of int and double, which is why it has separate operations for integer and double division.

Changing the behavior at this point is likely a breaking change.

[creativecreatorormaybenot]

@lrhn I see, what do you think about a warning of some kind?

I see two scenarios where warnings would make sense:

• Analyzer warning when doing double division on two integers and/or warning for occurences of / 0.

• Some kind of runtime feedback when the program runs into an infinite loop due to Infinity. Maybe that is impossible because the loop halts the VM.

[lrhn]

I think an analyzer hint for int / int might be reasonable ("Is this really what you mean?"). It's the case which trips up authors used to C/Java/C#, which all have non-object number types with automatic coercion.

A statically detectable x/0 might also be worth a hint too. It's always double.infinity or double.negativeInfinity, so it feels superfluous to write it that way. My guess is that in most cases, the 0 is not statically known, so it's probably not that useful as a hint.

Changing the semantics of loops to recognize a test which contains something < expressionWithInfiniteValue is non-trivial and potentially breaking (using infinity as bound is a reasonable default for loops that may or may not have a real limit).