Allow intersection type guards for multiple parameters

[SLaks]

Search Terms

type guard multiple parameters

Suggestion

I'd like to write a type guard that takes two parameters and changes the type of both of them.

Use Cases

My specific use case is to try to make the following pattern (somewhat) more type-safe:

class Foo<TFeature, TOther> {
    // If featureCtor is null, TFeature will never be used.
    constructor(private readonly featureCtor: { new(): TFeature } | null) { }

    isFeature(thing: any): thing is TFeature {
        return !!this.featureCtor && thing instanceof this.featureCtor;
    }

    bar(thing: TFeature|TOther) {
        if (this.isFeature(thing)) {
            // Type guard should prove that this.featureCtor is not null
            new this.featureCtor();
        } else {
            // Type guard should prove this
            const x: TOther = thing;
        }
    }    
}

Examples

isFeature(thing: any, ctor: { new(): TFeature } | null): (thing is TFeature)&(ctor is { new(): TFeature }) {
    return !!this.featureCtor && thing instanceof this.featureCtor;
}

It would be even nicer to allow type guards to operate on readonly fields, so I wouldn't need to pass this.featureCtor as a parameter.

I also tried

constructor(private readonly featureCtor: TFeature extends never ? null : { new(): TFeature }) { }

But that didn't work.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

[jyrodrigues]

Any news on this?

[quisido]

Seconding a need for this:

const isValidPair = (x: null | string, y: null | string): x is string & y is null {
  return typeof x === 'string' && y === null;
};

if (isValidPair(var1, var2)) {
  // know var1 is string
  // know var2 is null
}

[kayahr]

This would be useful for processing overloaded function parameters where it is enough to check one parameter to assume the type of the other parameter:

function nonsense(a: number, b: number): number;
function nonsense(a: string, b: string): string;
function nonsense(a: number | string, b: number | string): number | string {
    const isNumbers = (a: number | string, b: number | string): a is number & b is number 
        => typeof a === "number";

    if (isNumbers(a, b)) {
        return a * 10 + b * 100;
    } else {
        return a.length + b.length;
    }
}

[Fnxxxxo]

This is also convenient and meaningful for builders.

class Builder {
  private fixtureA: string | null = null
  private fixtureB: string | null = null
  // ... any other C, D, E ...
  public build() {
    if (this.ofTypeAB()) {
       return {}
    }
    if (this.ofTypeCDA()) {
       return {}
    }
  }
}

[m5r]

Hi, any updates?

[mordv]

I think it would be useful for otherwise annoying ref.current checking in react

const refsValued = <T extends unknown>(...refs: { current: T | undefined | null }[]): ...refs is { current: T }[] =>
  !refs.find((r) => !r.current);

[avalanche1]

bump!

[helmturner]

Would be great for syntax trees, as well.

I actually assumed this was possible, and tried the following syntaxes before finding this issue.

This syntax seems natural:

import {convert} from 'unist-util-is'
import type {Paragraph, Root} from 'mdast'

export const isNonNestedParagraph = convert<Paragraph>(
	(node, _, parent): node is Paragraph & parent is Root =>
		!!(node.type === "paragraph" && parent?.type === "root")
);

But it logically follows that a destructuring pattern could be used, as well.

Something like the following:

import {convert} from 'unist-util-is'
import type {Paragraph, Root} from 'mdast'

export const isNonNestedParagraph = convert<Paragraph>(
	(node, _, parent): [node, parent] is [Paragraph, Root] =>
		!!(node.type === "paragraph" && parent?.type === "root")
);

or:

import {convert} from 'unist-util-is'
import type {Paragraph, Root} from 'mdast'

export const isNonNestedParagraph = convert<Paragraph>(
	(node, _, parent): {node, parent} is {node: Paragraph, parent: Root} =>
		!!(node.type === "paragraph" && parent?.type === "root")
);

[joyt]

Would be really useful to have this. I wanted something like then when trying to type a deepEqual function:

// Would like assert that BOTH parameters are the intersection of their respective types
export function deepEqual<A, B>(a: A, b: B): (a is A & B) && (b is A & B) {...}

[fatso83]

Currently, the following is not possible:

if(isArrayOfSets([A,B])) {      // isArrayOfSets is a type predicate : `array is Set<any>[]`                                                                                                           
    return isSuperSet( [...A], [...B])                                                                                         
}   

Even though the predicate implicitly guarantees that A and B are both sets, it has lost this knowledge when applied to the arrays constituents. Instead I have to either repeat calls to type predicates for each variable like this:

if(isSet(A) && isSet(B)) {                                                                                                     
    return isSuperSet( [...A], [...B])    
}

Or I need to create throwaway intermediate objects to work around this, bloating the code:

const arr = [A,B]
if(isSetArray(arr)) {                                                                                                                
    const [newA, newB] = arr;                                                                                                        
    return isSuperSet( [...newA], [...newB])                                                                                         
}   

Would be cool to avoid this.

[trusktr]

A couple questions for this in the wild:

https://stackoverflow.com/questions/66880821/in-typescript-i-want-to-make-a-type-guard-for-multiple-arguments

https://stackoverflow.com/questions/58636396/type-guard-that-asserts-all-rest-parameters-are-not-undefined

[WillsterJohnson]

It's worth noting that without this feature TypeScript is logically inconsistent, see #54479

[LiChangyi]

Hi, any updates? I need it.

[fatso83]

If you want it, make it and supply a PR

[justingrant]

Another use case for this feature is validating that an object contains a particular key.

Assume I have a Record obj and a string key, where key may be a string literal, a string union type, or a string variable. Today, I'd need two different type guards with the same runtime implementation to validate that obj has an own property of key:

• One to narrow key to keyof obj so I can safely write obj[key]
• Another to narrow obj to a Record type with a property whose name is type typeof key, so that I can safely pass obj to other functions that require the narrowed type.

Ideally I could have a single type guard function that narrows both obj and key at the same time.

[bgenia]

Assume I have a Record obj and a string key, where key may be a string literal, a string union type, or a string variable.

Another to narrow obj to a Record type with a property whose name is type typeof key, so that I can safely pass obj to other functions that require the narrowed type.

If you do this with a union or a wide type like string you'd essentially prove the existence of multiple keys by checking for only one. Isn't that unsafe?

[helmturner]

Assume I have a Record obj and a string key, where key may be a string literal, a string union type, or a string variable.

Another to narrow obj to a Record type with a property whose name is type typeof key, so that I can safely pass obj to other functions that require the narrowed type.

If you do this with a union or a wide type like string you'd essentially prove the existence of multiple keys by checking for only one. Isn't that unsafe?

That depends entirely on the runtime implementation. By declaring functions as type guards or assertions, we are already being somewhat less safe by saying "Trust me, Typescript. I know what type this function returns."

[polurax]

I don't know if this issue makes the same request, but it would be great if the type guard also cast the others variables with the same generic type

an exemple

const isCat = (pet: Pet): pet is Cat => {
  // ...
}

const foo = <T extends Pet>(pet: T, shop: PetShop<T>) => {
  if (isCat(pet)) {
    // Here "pet" is Cat type, but "shop" is not PetShop<Cat> type
    // However, the variables share their T type, so they necessarily have the same
  }
}

[burtek]

@polurax the issue is, just because pet is Cat doesn't mean T is Cat as well. Example where code compiles but T is not Cat even though pet is Cat:

foo<Pet>(cat, dogShop)

[polurax]

@polurax the issue is, just because pet is Cat doesn't mean T is Cat as well. Example where code compiles but T is not Cat even though pet is Cat:

foo<Pet>(cat, dogShop)

I understand the problem. But it remains disconcerting.
Thank for the explanation

[polurax]

@burtek
I know it's not possible because of transpilation in javascript, but having a type guard that works on generic types directly without using a variable would be great.

[Lonli-Lokli]

With a brilliant fix #57465
Is it possible to reconsider if it possible to implement this one too?