Typescript: 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. https://github.com/Microsoft/TypeScript/issues/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 (https://github.com/Microsoft/TypeScript/pull/6532#issuecomment-174356151) 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.

[rotemdan]

_Edit: I got confused here between assertions on values and predicates between types, for some reason, please ignore this comment._

Just wanted to mention, on a somewhat unrelated note, that the way the T is U syntax uses the word is is quite ambiguous. Does it mean that type T _is exactly_ U (in the sense of the types being an exact structural or nominal match), or it means that T is a _subtype_ of U?

Common usage suggest the latter (in the sense that subclasses would pass instanceof checks for their super class) so it seems more appropriate that it would have been notated T extends U (and possibly the predicate is would be reserved for exact matches).

I feel it would be even more unfortunate that this misleading syntax is "abused" with composite formulas like T is U || V is W. Somewhat incidentally (almost entirely unrelated) I formulated a boolean syntax that used the more semantically accurate extends in #12942.

[aluanhaddad]

@rotemdan

Just wanted to mention, on a somewhat unrelated note, that the way the T is U syntax uses the word is is quite ambiguous. Does it mean that type T is exactly U (in the sense of the types being an exact structural or nominal match), or it means that T is a subtype of U?

the type predicate type annotation doesn't operate on two types it operates on a value and a type. A basic type predicate has the type

(x: any) => x is T

which means that if it returns true, the argument x is a subtype of T. It does not in any way mean that x is _is exactly_ a T.

What do you mean by nominal match? private members create pseudo nominal-like assignability.

Common usage suggest the latter (in the sense that subclasses would pass instanceof checks for their super class) so it seems more appropriate that it would have been notated T extends U (and possibly the predicate is would be reserved for exact matches).

Type predicates take a value and a TypeScript (i.e. erased) type. The instanceof operator in JavaScript, surfaced in TypeScript, takes _two_ values it doesn't take types at all...

[rotemdan]

@aluanhaddad

I 100% agree that the extends syntax would not be appropriate for type assertions on values, thanks for correcting me, I had types in mind (as that was something I was thinking about for other, unrelated purposes) and got a bit confused.

Now that I sort out the confusion is seems better. The funny thing is that I suggested a syntax for exact types that would read like just T, and I specifically had in mind that val is just T would read well. Silly me, got completely confused there..

_Edit: Maybe it was the title that used "type predicates", which probably intended to mean "value type guards", that got me confused_.

[RyanCavanaugh]

Bumping off my "stale" list because this is still a good idea