Boolean() cannot be used to perform a null check

[kujon]

TypeScript Version: 2.4.0

Apologies for today's issue raising binge.

Code

// Compiles
const nullCheckOne = (value?: number) => {
 if (!!value) {
 return value.toFixed(0);
 }

 return '';
}

const nullCheckTwo = (value?: number) => {
 if (Boolean(value)) {
 // Object is possibly 'undefined'
 return value.toFixed(0);
 }

 return '';
}

Expected behavior:
Both examples compile.

Actual behavior:
The latter example fails w/ Object is possibly 'undefined'.

Explanation
To my knowledge !!value and Boolean(value) are equivalent. I'm wondering what is the reason behind not supporting the second case. One reason I can think of would be an imported, non-typescript module, globally overriding it to something like: Boolean = (value) => !value.

[RyanCavanaugh]

I'm wondering what is the reason behind not supporting the second case

It's not supported because no one has done the work to support it yet.

One reason I can think of would be an imported, non-typescript module, globally overriding it to something

In general we don't account for this. Literally anything in the global scope could be mutated to be something different and it'd be insane to say Well you can't use substr because maybe someone messed with it.

I think we could replace the signature with

declare function Boolean<T>(x: T | false | 0 | "" | null | undefined): x is T;

which is almost correct (it fails to do the right then in the else case when x is 0 coming from a non-literal numeric type).

I've literally never seen someone use Boolean like this, though. Is there any difference between if (value) and if (Boolean(value)) ?

[kujon]

I don't think there's any, apart from implicit vs. explicit type cast. I personally use it, because it makes type conversion to primitives consistent (Boolean(1), String(1), Number('1'), etc.)

[Jessidhia]

One common pattern using the boolean constructor is .filter(Boolean) to remove falsy values from an array (including null and undefined).

[kujon]

@Kovensky - that is a good point. filter as it currently stands however, can't be used to implement the type guards either. Both of the examples below infer to (number | undefined)[]. Would also be really cool to address it.

const nonFalsy1 = [1, 2, undefined].filter(v => typeof v !== 'undefined');
const nonFalsy2 = [1, 2, undefined].filter(Boolean);

[ForbesLindesay]

Jakub Korzeniowski (@kujon) You can make .filter work with the custom function by adding explicit types:

const nonFalsy1: number[] = [1, 2, undefined].filter(
 <T>(v: T): v is Exclude<T, undefined> => typeof v !== 'undefined',
);

It's a little bit verbose, but very flexible.

[RyanCavanaugh]

This was reverted due to it causing a breaking change in 3.5. The simple repro looks like this:

declare const Bullean: {
 new(value?: any): Boolean;
 <T>(value?: T): value is Exclude<T, false | null | undefined | '' | 0>;
};

declare const arr: any[];
// Was any[], now (3.5) unknown[]
const arr2 = arr.filter(Bullean);

There might be something wrong in generic inference, but it's not yet clear. We'll need this scenario to work before adding it back in.