Using intersection with unions

[blakeembrey]

TypeScript Version:

1.8 / 1.9

Code

type Foo = { a: string } | { b: string }

interface Bar {
    c: string
}

type Baz = Foo & Bar

let baz: Baz

if (baz.a) {

}

Expected behavior: baz.a should be accessible, at least in 1.9 with the null checks.

Actual behavior: Property a does not exist on type

Edit: To clarify, I suspected it would have let me use it in the if condition in 1.9 since the introduction of strictNullChecks and flow control sounds like it would allow this functionality to pass.

[sandersn]

I think it's easier to read if you inline and shrink the types:

let baz: ({ a } | { b }) & { c };
if (baz.a) {
  let qux: { a } & { c } = baz;
}

The problem is that, even with control flow analysis, the compiler still doesn't do much "type math". All control flow will do is narrow -- that is, throw out members of a union. What needs to happen here is for the compiler to reach inside the intersection, throw out the nested union member, then create a new intersection type.

I will go see if there are other issues related to this. I think it comes up every couple of weeks.

[ahejlsberg]

The intersection type doesn't really have anything to do with the behavior here. Consider:

type Foo = { a: string } | { b: string };
let foo: Foo;
if (foo.a) {
}

We currently report an error because a is not present in all constituents of the union type. This is the reason for the error in the original example.

We might consider an alternate behavior in --strictNullChecks mode. We could say that the set of properties is every property in every constituent, with types of similarly named properties unioned together and with undefined added to their types unless the property is present in all constituents. This would make the original example work.

So, for purposes of property access, the type

type Foo = { a: string } | { a: string, b: string } | { a: number, c: number };

would behave like

type Foo = { a: string | number, b: string | undefined, c: number | undefined };

and it would require type guards to access the values in b and c.

[jeffreymorlan]

That kind of type guard is very error-prone since it depends on the other types in the union not having a property with the same name as an implementation detail:

interface I { a: string; }
interface J { b: string; }

class C implements I {
    a = "foo";
    private b = 42;
}

var c: I | J = new C();

c.b && c.b.toUpperCase(); // would throw TypeError at runtime if allowed

Allowing this would mean you could no longer add or rename an object's internal properties without worrying about whether it might conflict with a union somewhere.

(EDIT: fixed method name)

[blakeembrey]

@jeffreymorlan toupper would be caught as a method that does not exist by TypeScript.

[jeffreymorlan]

@blakeembrey I meant toUpperCase

[blakeembrey]

I know, but the comment still stands - TypeScript would error on toUpperCase.

Edit: I see your concern. I just tried out some tests.

Edit 2: I know it's probably a bit of work, but maybe it could work with existing flow control then? E.g. if (typeof c.b === 'string') and warn on other usages of it like if (c.b)?

Edit 3: Given all this, I'm not sure it's relevant now. I don't think there's anything stopping it from happening today. If you want to use one side of the union today, you'd need to rely on type coercion which removes type safety already. How are you using types like the one you mentioned above in today's code?

[RyanCavanaugh]

@blakeembrey I believe we do the distributive rules correctly now - can you confirm?