Divide by zero Typechecking

[ccorcos]

We have type literals for numbers already and a strictNullCheck compiler option -- wouldn't it be awesome if we had a type guard again divide-by-zero errors? I'm building a game that involved a lot of math, computing intersections of lines and such. But what if a line is parallel? It would be cool if the compiler would suggest this as a type error.

function f(): number | 0 {
    return 0
}

const y = 100 / f()

TypeScript Version: 2.7.0-dev.201xxxxx

[DanielRosenwasser]

Just to weigh in: given that number already implicitly includes 0, it seems

1. Kind of weird to say that number | 0 would be meaningfully different from 0.
2. Like kind of a weird responsibility to place on the user to remember to say "hey this number could be zero" when so could every other number.

[RyanCavanaugh]

Since this produces Infinity (which is meaningful) instead of NaN it's hard to even interpret it as an error.
intersectDistance(ray1, ray2) returns Infinity when they're parallel... not a problem?

[KiaraGrouwstra]

As Daniel said, this only make sense for numbers known at compile time.
With return types, T extends 0 ? Infinity : number could make sense.

Idris, famous for dependent types like this, uses safe_div : (x : Int) -> (y : Int) -> {auto p : so (y /= 0)} -> Int.

Given an equivalent to Flow's $Call (I'm gonna use regular function syntax for this), I'd imagine a TS equivalent to be implemented like declare function div<B extends number, NotZero = { (v: '1') => 'whatever'; }(B extends 0 ? '0' : '1')>(a: number, b: B).

To break that down, I'm catching the literal type of the denominator in a generic (B), checking whether it is 0, then plugging the answer to that into a partial function. When it turns out the answer does not match what we wanted, the requirements of the partial function are not satisfied, yielding a type error.

(I experimented with this idea in my PR for that feature (#17961), although my implementation ended up too glitchy, relying on synthetic type nodes that resulted in error tooltips showing up in the wrong place.)

[jendrikw]

Wouldn't something like this work if Infinity was a type?

declare function div(x: number, y: 0): Infinity
declare function div(x: number, y: number): number

[KiaraGrouwstra]

yes it would. :)

[ccorcos]

Interesting. It appears nothing actually breaks until something needs and actual number. It would be cool if Infinity and NaN could be considered separate types.

[weswigham]

You can actually kinda already define an Infinity numeric literal type. Just make a type alias to a number that's too big for JS to accurately represent and it'll round to Infinity. The issue is that the global Infinity constant isn't of this type 😉 , and declaration emit for this type may not work 😮 . It's super hacky. We should really just add the NaN and Infinity numeric literal types (back). 🐱 Plus, NaN even has wonky comparability we should encode 😄

[KiaraGrouwstra]

on second thought, I fear my partial function idea might well blow up as soon as it realizes you're potentially plugging in more than it could handle. hm.

[KiaraGrouwstra]

it seems @jcalz pulled off something like this at #21316 (comment) to disallow certain input

[AnyhowStep]

I'd really love to see Infinity and NaN types in TS.
It's always bothered me how they're just... Missing.

And adding a special case for the following doesn't seem too bad,

declare const x : any;
if (x === NaN) {
    //x is now of type `never`
}

[calimeroteknik]

@AnyhowStep reminder that there are many NaNs in IEEE 754 floats, and JS adds its own layer of bizarreness on top:

js> var a = 0/0;
NaN
js> var b = {} - 1;
NaN
js> a == b;
false
js> a === b;
false
js> isNaN(a);
true
js> isNaN(b);
true
js> NaN == NaN;
false

It raises the potential question of whether to lump them together.

[DanielHeath]

Could we define real, a subset of number which excludes Infinity or nan?

Then the type of division between two real values would be number, but addition / subtraction / multiplication would still be real.