TypeScript：没有显式返回类型的lambda中不会检查多余的属性

Question

In the following example im trying to figure out why my typing works for all parts of my object apart from my reducer return type?

If i explicitly set: reducer: (state, action): CounterState the compiler complains (as expected) that i'm not returning the right state. The thing is, i don't see why i should have to do this seeing as i'm already enforcing this within my Config type??

The simplified example:

interface CounterState {
    counter: number;
}

type Reducer = () => CounterState

const reducer1: Reducer = () => ({
    counter: 1,
    foo: 'bar' // no errors, why?
})

const reducer2: Reducer = (): CounterState => ({
    counter: 1,
    foo: 'bar' // error: Object literal may only specify known properties
})

Answer 1

Type compatibility in TypeScript is based on structural subtyping.

https://www.typescriptlang.org/docs/handbook/type-compatibility.html

Typescript designed to allow extra properties. But in some places we have a little inconsistent behaviour and it claims object literal may only specify known properties . Such behaviour is more expected but it is not a structural subtyping...

https://medium.com/@KevinBGreene/surviving-the-typescript-ecosystem-interfaces-and-structural-typing-7fcecd54aef5

Answer 2

Finally I found the issue in GitHub, exactly about the problem. In short:

Ideally this would be an error. Unfortunately it turns out to be very difficult to fix this without possibly having consequences in terms of runaway recursion and/or performance

Original answer: Since typescript 1.6, object literals mustn't have extra properties . But if you cast an object to the type, extra properties are allowed. For example:

const state: CounterState = {
    counter: 1,
    foo: "bar" // Error, unknown property 'foo'
};

const state2 = {
    counter: 1,
    foo: "bar" // no errors
} as CounterState

It looks very similar to your problem, when you specify the lambda return type explicitly, the first rule is applied. But, if the return type isn't specified, the compiler thinks: "ok, may be I can cast the object to the CounterState... Is it ok? I'm not sure... But, I will try!", and the second rule is applied.

But I cannot refer to any documentation or compiler specification, which describes such behaviour, I didn't found it too.