Function unexpectedly allows returning arguments object directly if it's a superset of the return type

[jdmunro]

TypeScript Version: 2.8.1

Search Terms:

strict interface return check

Code

interface A {
    firstName: string
    lastName: string
}

interface B {
    firstName: string
}

const worksButMaybeShouldnt = (a: A): B => a // I expected an error here but none occurs

const correctlyFails = (a: A): B => ({...a}) // I expected this error

Expected behavior:

I expected the worksButMaybeShouldnt function to have a compile error. It returns an object that has a different shape to the expected return type (it has an extra property: lastName). The correctlyFails example does something similar, effectively returning a copy of the input, and this correctly exhibits a compile error.

I would expect that the above 2 examples would both have compile errors.

Actual behavior:

There is no compile error at all and I'm able to return an object with a different shape (a superset of the return type).

Playground Link: http://www.typescriptlang.org/play/#src=interface%20A%20%7B%0D%0A%20%20%20%20firstName%3A%20string%0D%0A%20%20%20%20lastName%3A%20string%0D%0A%7D%0D%0A%0D%0Ainterface%20B%20%7B%0D%0A%20%20%20%20firstName%3A%20string%0D%0A%7D%0D%0A%0D%0Aconst%20worksButMaybeShouldnt%20%3D%20(a%3A%20A)%3A%20B%20%3D%3E%20a%20%2F%2F%20I%20expected%20an%20error%20here%20but%20none%20occurs%0D%0A%0D%0Aconst%20correctlyFails%20%3D%20(a%3A%20A)%3A%20B%20%3D%3E%20(%7B...a%7D)%20%2F%2F%20I%20expected%20this%20error%0D%0A

Related Issues:

#3823
#391

Duplicate of #12936 -- by default all types in TypeScript support subtyping and there's no way to turn it off. There's an exception for object literals since if you write const o: A = { ... } we assume you only intend to write properties in A, but not for variables.

[RyanCavanaugh]

This is a bug but in the reverse direction - we shouldn't enforce known property checks on spreaded properties

@RyanCavanaugh Duplicate of #19775 then

[jdmunro]

Thanks for the explanation! It wasn't obvious to me at first.

const example1 = (a: A): B => {
    const c = { ...a }
    return c // works
}

const example2 = (a: A): B => {
    return { ...a } // error
}

You can circumvent the known property checks on spread properties, whether inadvertently or not, using the above. I imagine the above are intended to have the same behaviour.

@jdmunro #7547