Object spread fails to type check

[arv]

Given

/** @param {{x: number, y: string}} x */
function f(x) {}

/** @type {{y: string}} */
const o = {y: "a"};

f({x: 1, ...o})

https://closure-compiler.appspot.com/home#code%3D%252F%252F%2520%253D%253DClosureCompiler%253D%253D%250A%252F%252F%2520%2540compilation_level%2520ADVANCED_OPTIMIZATIONS%250A%252F%252F%2520%2540output_file_name%2520default.js%250A%252F%252F%2520%2540formatting%2520pretty_print%250A%252F%252F%2520%253D%253D%252FClosureCompiler%253D%253D%250A%250A%250A%252F**%2520%2540param%2520%257B%257Bx%253A%2520number%252C%2520y%253A%2520string%257D%257D%2520x%2520*%252F%250Afunction%2520f(x)%2520%257B%257D%250A%250A%252F**%2520%2540type%2520%257B%257By%253A%2520string%257D%257D%2520*%252F%250Aconst%2520o%2520%253D%2520%257By%253A%2520%2522a%2522%257D%253B%250A%250Af(%257Bx%253A%25201%252C%2520...o%257D)

I'm getting a type error. I assume this is just because object spread is not fully implemented yet?

[brad4d]

It is true that the typecheck passes haven't yet been updated to understand object spread.
Instead object spread is transpiled away before type checking.
I wouldn't expect that to change until sometime next year.

Since o is a constant, one would expect the compiler to be able to figure out that the object literal
passed to f has a y property containing a string. The transpilation of object rest probably obscures
this. It is possible that this issue will be solved "for free" when the transpilation moves after type checking, but I'm not certain of that.

In any case I wouldn't expect us to work at fixing it until the transpilation pass gets moved.

In the meantime the workaround is to use a cast.

[teppeis]

FYI: TypeScript supports it (sample code)

[brad4d]

Internal issue created http://b/122266991

[brad4d]

@teppeis thanks for pointing that out, but we were actually aware of this.

We disagree with TypeScript on this issue because we have different goals.
TypeScript doesn't care about optimizing output code size, but that's one of our primary focuses.

Some of our advanced optimizations rely on the compiler knowing about all places where a given property is read or written and can break code when some of them are hidden.
Type errors like this one help our users recognize that they are writing code that closure-compiler cannot analyze as well and could be problematic to compile.