Allow intersection type guards for multiple parameters

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)

Any news on this?

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
}

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;
    }
}

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 {}
    }
  }
}

Hi, any updates?

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);

bump!

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")
);

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) {...}

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.

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

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

Hi, any updates? I need it.

If you want it, make it and supply a PR

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.

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?

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."

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
  }
}

Valentin Turpault (@polurax)

Valentin Turpault (@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)

Valentin Turpault (@polurax)

Valentin Turpault (@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

Bartosz (@burtek)

Bartosz (@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.

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

Much needed feature. In the meanwhile I use a workaround:

class A {
  filter<
    K extends keyof this,
    V extends (typeof this)[K],
    S extends K,
    T extends V,
  >(
    callback:
      | ((key: K, value: V, i: number, arr: [K, V][]) => key is S)
      | ((key: K, value: V, i: number, arr: [K, V][]) => value is T),
  ) {
    ...implementation...
  }
}

Navigation Menu

Repository navigation

Allow intersection type guards for multiple parameters #26916

Search Terms

Suggestion

Use Cases

Examples

Checklist

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow intersection type guards for multiple parameters #26916

Description

Search Terms

Suggestion

Use Cases

Examples

Checklist

Activity

jyrodrigues commented on May 20, 2019

quisido commented on Nov 19, 2019

kayahr commented on Dec 5, 2019

Fnxxxxo commented on Dec 14, 2019

m5r commented on Jul 27, 2020

mordv commented on May 16, 2021

avalanche1 commented on May 24, 2022

helmturner commented on Jul 15, 2022

joyt commented on Dec 7, 2022

fatso83 commented on Jan 30, 2023

trusktr commented on Mar 2, 2023

WillsterJohnson commented on Jun 1, 2023

LiChangyi commented on Nov 14, 2023

fatso83 commented on Nov 14, 2023

justingrant commented on Apr 10, 2024

bgenia commented on Apr 10, 2024

helmturner commented on Apr 10, 2024

polurax commented on May 30, 2024

burtek commented on May 30, 2024

polurax commented on May 30, 2024

polurax commented on May 30, 2024

Lonli-Lokli commented on Sep 16, 2024

sdwvit commented on Oct 2, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions