Array filter() by element constructor returns never[]

[iknowcss-invenco]

🔎 Search Terms

array never filter

🕗 Version & Regression Information

• This changed between versions 5.4.5 and 5.5.2

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.5.2#code/IYIwzgLgTsDGEAJYBthjAg4gUwHbagEtYBhVdBAbwCgEEAHKAewm3mwBMkndIoBXeEygAKevxDJiCAG7Bk-bAC4EfQrgDmASioBfavuoo0GEj1hRsrMiYTYAHq1wcMOfEVLkMNOrB59BCGEROQVlVWh1bSpaOlV+egIRAAMzXAsrcIASSlDFXWStAG5Y-UM-XkRsZGwAWzwIMBU3AmIbdABtAF0EAF4EDvwAdwQ0jOsvEQByYCmtLpKjf0QAM0JkVksOAFEa+txGvrs9hrAAOjWNpJFquoadXoA+Y7uDs4qAoSg+3v6xywmJmK1Gol02nF2r0aHQADF0znlsGcggBlSKaETAoA

💻 Code

abstract class GenericClass {
  protected constructor(public value: string) {}
}

class ConcreteClass extends GenericClass {
  constructor(value: string) {
    super(`Concrete: ${value}`);
  }
}

const elements: GenericClass[] = [new ConcreteClass('a')];

const filteredElements = elements.filter((element) => element.constructor === ConcreteClass);

filteredElements[0].value.toString();
//                  ~~~~~ 
// Property 'value' does not exist on type 'never'.

🙁 Actual behavior

The return type from the .filter() expression is never[]

🙂 Expected behavior

The return type from the .filter() expression is GenericClass[]

Additional information about the issue

I searched through the open issues in the days since 5.5.2 were released but I could not find any which matched this case. Apologies if I missed anything. I've tried to reduce this down to the most minimal example that I can.

[fatcerberus]

Changed in 5.2 5.5 so probably a result of automatic type predicate inference

[whzx5byb]

The return type of filter callback (element) => element.constructor === ConcreteClass is inferred as element is never in 5.5.2 because of #57465. I would suggest using (element) => element instanceof ConcreteClass instead.

[IllusionMH]

Related #16035

[fatcerberus]

Why are we calling this “5.2”?

Oops, typo and/or me being in too much of a rush. Fixed now.

[iknowcss-invenco]

I would suggest using (element) => element instanceof ConcreteClass instead.

Yes, I agree this works and is more idiomatic. I will change this in my code to fix the problem. I wanted to report it in case other projects unexpectedly break while trying to do a minor bump. I'm not sure if 5.5.2 fixes a long standing bug or not, but regardless it was a surprise to have a broken build after this minor upgrade. Thanks for your work on it 🙏

[fatcerberus]

@whzx5byb Thats weird though because #16035 suggests this condition doesn’t narrow

[whzx5byb]

@fatcerberus Actually the .constructor narrowing works only when the target is a union type and it must be compared using === (or ==, but not for switch clause) operator. I'm very surprised that it even works for the switch (true) pattern as long as there is a === comparison!

class A {
  a!: number;
}

class B {
  b!: number;
}


function fn(input: A | B) {
  switch (input.constructor) {
    case A:
      input.a // <- not work
  }

  switch (true) {
    case input.constructor === A:
      input.a; // work!?
  }
}

But anyway, in the OP's case the narrowing target is not a union type, and .constructor === comparison will always narrow it to never.

[ahejlsberg]

Seems to me the real issue is this:

class GenericClass {
    constructor(public value: string) { }
}

class ConcreteClass extends GenericClass {
    constructor(value: string) {
        super(`Concrete: ${value}`);
    }
}

function foo(obj: GenericClass) {
    if (obj.constructor === ConcreteClass) {
        obj;  // never, Wat?
    }
}

It's obviously possible for obj.constructor to be ConcreteClass since that class is derived from GenericClass. The error that this issue reports is simply a follow-on effect of the incorrect narrowing that gets picked up in an inferred type predicate.

[ahejlsberg]

It goes all the way back to #32774 that implemented "constructor type guards". There is no logic to deal with derived classes.

[fatcerberus]

#32774 that implemented "constructor type guards"

Wait, why is #16035 still open then?

[typescript-bot]

This issue has been marked as "Design Limitation" and has seen no recent activity. It has been automatically closed for house-keeping purposes.