Better propagation of type predicate signatures

[zpdDG4gta8XKpMCd]

declare function isNumber(value: {}): value is number;
declare const values: {}[];
declare function filterAs<a, b extends a>(values: a[], isIt: (value: a) => value is b): b[];
const yayNumbers = filterAs(values, isNumber); // number[]
const ohNoNotAgain = filterAs(values, x => isNumber(x)); /* <-- expected to work,
actual: Argument of type '(x: {}) => boolean' is not assignable to parameter of type '(value: {}) => value is {}'.
 Signature '(x: {}): boolean' must have a type predicate. */

[DanielRosenwasser]

There actually is a way, but it's cumbersome.

const yayayayayayay = filterAs(values, (x): x is number => isNumber(x));

[aluanhaddad]

Is there a way that this can be improved? It seems very counterintuitive for the type of the predicate to be lost when passed as a callback.

[DanielRosenwasser]

I'd like to think so, but there needs to be a proposal. I'd like to think that for the following:

declare function isNumber(x: any): x is number;
declare function isString(x: any): x is string;

function isSomething(x: any) {
 return isNumber(x) || isString(x);
}

isSomething becomes a predicate on x for string | number.

But for the following

declare function isNumber(x: any): x is number;
declare function isString(x: any): x is string;

function uhhhh(x: any, y: any) {
 return isNumber(x) || isString(y);
}

we'd like to potentially maintain the checks from each predicate, but we don't have a way to encode those guarantees on the signature of uhhhh. Maybe that's okay though.

[zpdDG4gta8XKpMCd]

What I dont understand is that why 10% of corner cases prevent 80% of straightforward cases from being implemented. Can we error in these cases you mentioned? Or can we default to the current fall back to conventional boolean as it currently is?

[aluanhaddad]

It seems like the return type of uhhhh would be (hypothetically)

x is number & y is any | x is any & y is string

But while this could be useful maybe it doesn't need to block inference that doesn't require new syntax to express explicitly. It seems like that would be an orthogonal feature, something like "Correlated User-Defined type Gards". I may be misunderstanding the issue however.

[gcnew]

Aleksey-Bykov Implementing features that are useful but not entirely thorough attracts a lot of criticism and is oftentimes even questionable. e.g. #13002

[zpdDG4gta8XKpMCd]

Exactly, since we dont get to choose, the type guards don't work at certain positions, let's make them more thorough is my message here, and lets make readonly right by breaking some crappy code (#6532 (comment)) that is standing on the way, that sarcasm me gets too.

[aluanhaddad]

I think it is just unexpected. I think it is surprising because type predicates are as rich and compositional as they already

if (true || isNumber(x) && isString(x) && isFunction(x)) {
 x // {}
}
if (false || isNumber(x) && isString(x) && isFunction(x)) {
 x // number & string & Function
}

so one may be surprised when they do not work

if (!true || isNumber(x) && isString(x) && isFunction(x)) {
 x // {}
}
if (!false || isNumber(x) && isString(x) && isFunction(x)) {
 x // {}
}

these are rather academic however.

[zpdDG4gta8XKpMCd]

I would like to add that && combinator can be replaced by successive application of different typeguards

As for || it doesn't make much sense if we keep in mind that typeguards are for narrowing (not widening), I might be wrong about it, so a real life example proving me wrong would be helpful. Narrowing from any to string | number looks made up, why not to narrow straight to number or string?

With this said there seem not to be a real situation that would require && and || combinators, ans if so it doesn't seem rational to invest in solving a nonexisting problem.

On the other hand the orifinal situation with type guards used for filtering is very real and needs some attention

[zpdDG4gta8XKpMCd]

Situations that imply string | number are usually (in our code) explicitly stated: string | number | boolean | null | undefined | Function and then all it takes is to chip the cases off one type at a time:

if isNumber ... else if isString ... else if isBoolean

[aluanhaddad]

Aleksey-Bykov I agree that these are edge cases. I also like the chip them off one type at a time approach and use it myself.