Can cast to partial interface of types unless you also provide an optional member

[lucasray]

TypeScript Version: 2.0.X / 2.1.X

Code

interface Foo {
  required1: string;
  required2: string;
  optional?: string;
}

const foo1 = { required1: "hello" } as Foo; // succeeds
const foo2 = { required1: "hello", optional: "bar" } as Foo; // fails

Expected behavior:
Expect similar behavior in the above two casts -- either for the foo1 cast to also fail (ideal, as required2 is missing), or for the foo2 cast to succeed.

Actual behavior:
Actual behavior in comments -- foo1 cast succeeds while foo2 fails.

[DanielRosenwasser]

I feel like @JsonFreeman has brought this up before.

[JsonFreeman]

This does seem like a familiar problem, though I am surprised that this does not work. Is there a type relation dedicated to checking type assertions?

I suspect it has to do with the fact that the object is being converted to a type where one property optional is less present, but another property required2 is more present. In general the limitations on type assertions have been because even for types that seem obviously related, the relation does not lean unanimously in any one direction.

[DanielRosenwasser]

We use the comparable relationship for each direction, which is mostly just assignability except that a type S is comparable to a union T₁ | ... | T_n, if S is assignable to any T_i.

That's exactly it I think. I dug up the issue I was thinking about: #1447

[JsonFreeman]

I think one option is to simply ignore optionality in the comparable relation. That is a targeted fix, though it might break other cases.

Another option is to try to generalize this. When you check assertions, you could ask the question: Is there any value that can simultaneously inhabit both of these types. This might be too broad because usually the answer will be yes, you could just intersect the two types. For objects that are completely unrelated, an object that aggregated both of their properties would inhabit both types.

It feels like for object types, it might be useful to think about this in a similar way to the rule about excess properties. There was nothing type theoretic that said excess properties were not allowed, but if you passed an object with excess properties, it was likely that the user had misspelled a property. In other words, what is the mistake that this check is trying to catch?

[DanielRosenwasser]

I think it is close in spirit to excess property checking.

I think one option is to simply ignore optionality in the comparable relation. That is a targeted fix, though it might break other cases.

I was thinking about this as well - comparability is about the idea that the source and target may actually be the same at runtime.

[DanielRosenwasser]

Check out #12202 for a fix.

[lucasray]

Great, thanks for the quick turnaround and fix!