Cast permitted with missing properties on object literals

[mathias999us]

TypeScript Version: 2.1.1 / nightly (2.2.0-dev.201xxxxx)

Code

interface ITestOne {
    a: string;
    b?: string;
}

var test1: ITestOne = {} as ITestOne; // ALLOWED - Why is this allowed?
var test2: ITestOne = { b: 'blah' } as ITestOne; // ALLOWED - Why is this allowed?
var test3: ITestOne = { b: 'blah', x: 'meh' } as ITestOne; // ERROR - Property a is missing

Expected behavior:

Expected behavior is that test2 case is not permitted. NOTE: This was working correctly as of TypeScript 1.7.

Test3 is an example of how to perturb the "correct" behavior.

I have not been able to find any documentation about why test1 is allowed. One could make the case for filling out an empty object literal after it has been instantiated empty, but this seems like a dangerous thing to allow. Again it permits the case where we have an object of ITestOne that does not meet the interface definition.

Actual behavior:
test2 passed compiler checks, but produces an invalid object literal without property a.

See SO post for some further background:
http://stackoverflow.com/questions/41941125/intellisense-with-union-types

[mhegazy]

Type Assertion spec

In a type assertion expression of the form < T > e, e is contextually typed (section 4.23) by T and the resulting type of* e* is required to be assignable to T, or T is required to be assignable to the widened form of the resulting type of e, or otherwise a compile-time error occurs. The type of the result is T.

What type assertion does, it tells the compiler to "shut up" and trust you. The operator behaves both as an upcast and as a downcast operator. The only check is that the one of the types is assignable to the other.

In the example above, for test: {a: string, b?:string} is assignable to {} (which requires no arguments); for test2 {a: string, b?:string} is assignable to {b:string}, since the type of the only required argument in the target b matches. for test3 neither {a: string, b?:string} is assignable to {b:string, x:string} since it is missing x nor {b:string, x:string} to {a: string, b?:string} since it is missing a.

[mathias999us]

Thank you - this is very helpful. At this risk of turning this into a question thread, it's not clear to me why asserting that { a:string, b?:string } is assignable to {} is useful in the case where the assignment is the other way around (from {} to { a:string, b?:string }). i.e. Why does it matter if the target type is assignable to the source type? Why check at all?

[mhegazy]

At this risk of turning this into a question thread, it's not clear to me why asserting that { a:string, b?:string } is assignable to {} is useful in the case where the assignment is the other way around (from {} to { a:string, b?:string }). i.e. Why does it matter if the target type is assignable to the source type? Why check at all?

Not sure i understand your question here. the compiler is trying to help verify that this is either a valid up cast or down cast, and not two completely unrelated types. beyond that, it is up to you to decide whether this was a valid conversion or not.