Strange behavior with union of complex types

[Roaders]

TypeScript Version: 2.8.1

Search Terms:
union complex types

Code

interface IOne{
    stringOne: string;
    numberOne: number;
}

interface ITwo{
    stringTwo: string;
    numberTwo: number;
}

type IEitherOr = IOne | ITwo;

var itemThree: IEitherOr = {
    numberOne: 42343,
    stringOne: "",

    numberTwo: "sdfsd"
}

Expected behavior:
This should throw an error.
IMHO I think that there are 3 issues here.

• First off I was surprised that numberTwo was allowed AT ALL. I think that the type should be either IOne OR ITwo, not a mix of the two.
• If we do allowed mixed types (which I don't think we should) then surely if there are any properties for ITwo we should require all of them. This should throw an error unless we have specified both numberTwo and stringTwo
• lastly it's not even type checking numberTwo. It is typed as a number but it's fine with a string.

Actual behavior:
The compiler is fine with this!

Playground Link:
Link

Work Around:

You can enforce proper type checking on the secondary mixed type like this:

type IFixedEitherOr =
    ( IOne & Partial<ITwo> ) 
    |
    ( ITwo & Partial<IOne> );

var itemFour: IFixedEitherOr = {
    numberOne: 42343,
    stringOne: "",

    numberTwo: "dfgdf" // this errors
}

The code above correctly fails to compile.

[jack-williams]

Related: #20863

There is nothing unsound about this interaction but it can be undesirable which is why there is excess property checking at initialisation, however I believe this does not work for unions without a discriminant (see related issue).

[Roaders]

I really can't see how you can say there is nothing unsound when I have a number property assigned to a string!

[jack-williams]

The type IEitherOr does not promise that property numberTwo will be a type number. It promises that either:

• stringOne will be string and numberOne will be number, OR,
• stringTwo will be string and numberTwo will be number.

If you state IEitherOr using intersection and union (which is roughly equivalent), and consider them like logical and, and logic or. Then you have:

• ({stringOne: string} & {numberOne: number}) | ({stringTwo: string} & {numberTwo: number})

which can be satisfied with only {stringOne: string} and {numberOne: number}: you never need to claim anything about numberTwo.

Note: you can get unsound behaviour from this object:

if ("numberTwo" in itemThree) {
    itemThree.numberTwo // narrows to ITwo, unsafe!
}

however this is from narrowing rules for union, not assignment compatibility.