Typescript: Spread operator does not call property getters

[andreashuber69]

Search Terms:
spread operator, property getter

Code

interface IWhatever {
    readonly value: number;
}

class Whatever implements IWhatever {
    public get value() {
        return 42;
    }
}

const whatever: IWhatever = new Whatever();
const obj = { ...whatever, otherValue: 43 };
console.log(obj);

Expected behavior:
{ value: 42, otherValue: 43 }

This is expected because a readonly property of an interface can be implemented with a getter. The code using the interface cannot know that the property is implemented with a getter and therefore expects to see the property of the interface in the result.

Actual behavior:
{ otherValue: 43 }

Playground Link:
Link

Related Issues:

[RyanCavanaugh]

TypeScript doesn't change the behavior of JavaScript.

[andreashuber69]

That's a fair point, ts isn't responsible for how js works. However, if we expand the example code just a little bit, e.g. as follows...

interface IWhatever {
    readonly value: number;
}

class Whatever implements IWhatever {
    public get value() {
        return 42;
    }
}

class Utility {
    public static Do(x: IWhatever) {
        return x.value;
    }
}

const whatever: IWhatever = new Whatever();
const obj = { ...whatever, otherValue: 43 };
console.log(Utility.Do(obj));

... it becomes clear that the compiler does assume that obj implements the interface, otherwise the code should not compile. More precisely, the compiler falsely assumes that obj will always have a value property even though there's the possibility that it might not.

[RyanCavanaugh]

See also #26287

I'm not sure what you're proposing happen. We don't track own/enumerability (see other open issues on that) so what line should be an error?

[andreashuber69]

I'm not sure what should happen, I just think this is a hole in the type system.

If I had to implement this, I'd say the compiler should not make any assumptions what properties are added to an object by the spread operator. So, the call to Utility.Do should be flagged because obj cannot be guaranteed to implement the IWhatever interface. The programmer could still make the call by casting obj to IWhatever first.

[andreashuber69]

And yes, #26279 is very related. The issue only talks about classes with getters, so I'm not sure whether the fix would also correct the issue WRT interfaces as shown above.

[RyanCavanaugh]

It wouldn't fix this case due to the indirection via IWhatever

[andreashuber69]

Ok, thanks. How are we going forward with this problem (if it is one)? Should I file another issue that more succinctly explains the matter?

[RyanCavanaugh]

I don't think there's anything to do about it unless we were going to add a --strictOwnAndEnumerability flag to enforce tracking ownness/enumerability on all properties, which seems extraordinarily unlikely.

[CHBaker]

Would it be possible to type cast the spread operator value with the properties it is filling in? I think that would be useful instead of assuming the coder is correct