Repository navigation
Can cast to partial interface of types unless you also provide an optional member #12187
Description
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; // failsExpected 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.
Activity
DanielRosenwasser commentedon Nov 12, 2016
I feel like Jason Freeman (@JsonFreeman) has brought this up before.
JsonFreeman commentedon Nov 12, 2016
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
optionalis less present, but another propertyrequired2is 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 commentedon Nov 12, 2016
We use the comparable relationship for each direction, which is mostly just assignability except that a type S is comparable to a union T1 | ... | Tn, if S is assignable to any Ti.
That's exactly it I think. I dug up the issue I was thinking about: #1447
JsonFreeman commentedon Nov 12, 2016
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 commentedon Nov 12, 2016
I think it is close in spirit to excess property checking.
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 commentedon Nov 12, 2016
Check out #12202 for a fix.
lucasray commentedon Nov 13, 2016
Great, thanks for the quick turnaround and fix!