Narrowing types based on property access

[trusktr]

Suggestion

🔍 Search Terms

type narrowing based on property checks, similar to in operator.

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code. I don't think so, because errors are currently produced, but now there would be narrowing instead of errors.
• 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. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Lot's of JS code uses duck typing. For example:

📃 Motivating Example

class Foo {
    bar: object = {}
    meth() {}
}

declare const f: Foo | Foo[]

if (f.bar) { // Error, bar property does not exist on Foo | Foo[]
  f.meth()
}

playground

💻 Use Cases

We can currently do something similar that actually works:

class Foo {
    bar: object = {}
    meth() {}
}

declare const f: Foo | Foo[]

if ('bar' in f) {
  f.meth()
}

playground

But using a property check would allow us to write code like we can (and like currently exists) in plain JS. The f.bar check would behave similar to the 'bar' in f check, and would narrow the type.

This would need to be limited to certain property types. For example, if Foo.bar were a number, then a value of 0 can make it result in a false even if the property exists. In this case TS would need to throw an error and would not be able to perform type narrowing in such cases.

If the type of Foo.bar is something that is always truthy (f.e. bar: Record<Foo, Bar> is always truthy) then type narrowing can be performed. The system would have to clearly report errors in cases when type narrowing can not be confidently performed based on the encountered type.

[MartinJohns]

Duplicate of #39065.

You're wrongly assuming that just because a truthy bar property exists it must be a Foo object. Types are not sealed in TypeScript, additional properties are allowed. This issue already exists with the in operator and is unsound, but with your proposal it would get significantly worse.

[FilipeBeck]

You're wrongly assuming that just because a truthy bar property exists it must be a Foo object

declare const f: Foo | Foo[]

If f is Foo | Foo[] and bar exists in f, then it is a instance of Foo. I don't see problems using 'bar' in f, but the premise is true based on the type Foo | Foo[].

[fatcerberus]

Not necessarily:

interface Foo {
    foo: string;
}

interface Bar {
    foo: number;
    bar: string;
}

// not a valid `Bar` because `Bar` calls for `foo: number`.
// it IS a valid `Foo`, though!
const thing = { foo: "pig", bar: "cow" };
doIt(thing);

function doIt(foobar: Foo | Bar)
{
    if ('bar' in foobar) {
        foobar.foo;  // hover here - TS thinks it's a `Bar` and therefore that `foobar.foo` is a number
    }
}

[FilipeBeck]

Yes, but, in this case, f is Foo | Bar and Bar has foo too. Now, in Foo | Foo[], Array<Foo> does not have foo. Only Foo has foo. Look the playground link in issue description. The compiler sees f as Foo in 'bar' in f

[FilipeBeck]

As I said, based in type Foo | Foo[], the premise is true

[fatcerberus]

It's completely possible for Foo[] to have a foo property. One can make subtypes of Array.

[FilipeBeck]

For example, if Foo.bar were a number, then a value of 0...

This is reason why (if f.bar) doesn't always work

[FilipeBeck]

It's completely possible for Foo[] to have a foo property. One can make subtypes of Array.

Yes. Look the playground link and do this. You will get a compiler error

[FilipeBeck]

One can make subtypes of Array.

f is Foo | Foo[] and not Foo | ASubtypeOfArrayThatContainsAFooProperty

[MartinJohns]

class Foo {
    bar: object = {}
    meth() {}
}

const f: Foo | Foo[] = Object.assign([], { bar: {} });

console.log(Array.isArray(f))
console.log('bar' in f)

Will print out true two times. Playground link

---

Also just pointing out that you can edit your comments, no need to add comment over comment.

[fatcerberus]

ASubtypeOfArrayThatContainsAFooProperty is assignable to Array. That was my point. Given a value of type Foo, you can't assume you don't have a subtype with unknown properties.

[FilipeBeck]

const f: Foo | Foo[] = Object.assign([], { bar: {} });

You are assing bar to [] using Object.assign. In if('bar' in f), the compiler continue seeing f as Foo

[fatcerberus]

I give up.

[MartinJohns]

the compiler continue seeing f as Foo

Yes, I mentioned this unsoundness with the in operator in my first comment already. See also #34975.

[FilipeBeck]

You can do Object.assign in any var (or (f as any).anything = 10). The error is declaring the type wrong in this case. The compiler is right on seeing f as Foo on if('bar' in f) when f is Foo | Foo[]