Object.assign not type checking

[OliverJAsh]

TS 2.0.3

Given:

(() => {
    type State = { foo: string };
    const state: State = { foo: 'bar' };
    const newState: State = Object.assign({}, state, { foo: 1 }) // I expect this to error
})();

I swear this used to work!

[Arnavion]

As I explained on IRC, the result of assign is { foo: string & number }, so TS considers it okay to be assigned to { foo: string }.

[sandersn]

I am close to having a PR for spread types, so when those are in, Object.assign will change to have the correct type:

assign<T, U>(target: T, source: U): { ...T, ...U }

Right now I am working in the branch object-rest-spread-WIP if you want to follow along.

[sandersn]

(also you'll just be able to use the syntax { ...state, foo: 1 } instead of calling Object.assign)

[Arnavion]

Nathan Shively-Sanders (@sandersn) So with your change, the result of assign would be { foo: number } ?

[sandersn]

Yes, which is not assignable to State, so it would error as desired.

[OliverJAsh]

Thanks, that's great Nathan Shively-Sanders (@sandersn). I look forward to it!

Arnav Singh (@Arnavion) How come this works?

const someState: { foo: string } & { foo: number } = { foo: 1 }

I think you explained why in IRC, but I'm not sure I completely understand. Are you saying in the above example we're trying to assign number to string & number which is an error, but if we try to assign string & number to number then it is allowed?

[Arnavion]

DerivedClass is assignable to BaseClass because all DerivedClass are also BaseClass. Similarly string & number is assignable to number because all string & number are also number.

BaseClass is not assignable to DerivedClass because an arbitrary BaseClass is not necessarily also a DerivedClass. Similarly number is not assignable to string & number because an arbitrary number is not necessarily also a string.

[OliverJAsh]

That makes sense, thank you Arnav Singh (@Arnavion):

    // number is not assignable to string & number because an arbitrary number is not necessarily also a string.
    const x = 'foo' as string & number
    const x1: number = x
    // string & number is assignable to number because all string & number are also number.
    const x2: string & number = 'foo'

[danielearwicker]

Nathan Shively-Sanders (@sandersn), this looks very good! Shouldn't the new type of Object.assign be:

assign<T, U>(target: T, source: U): T & { ...U }

i.e. all type features of target are preserved, with only properties from U tacked on. This covers the very common use case of adding properties to functions.

[sandersn]

Daniel Earwicker (@danielearwicker) that's not quite right either because if the function already has a property that source overwrites then intersection doesn't give the right answer either. If we take as given that our only operators are spread and intersection, then I'd go with the stricter and more accurate one. (Of course we could introduce two kinds of spread but I don't like that idea.)

Can you point me to some source that spreads properties into functions? I'm always interested in collecting uses of the spread type — previously I thought that real-world uses were always with property bags.

[danielearwicker]

Yes, I see. I haven't been using object spread operator for this purpose (I only use TS) but I have been using Object.assign and similar functions to do the same thing.

Hiding in plain sight, jQuery's $ is probably the famous example of a function with properties. It's very handy to be able to encapsulate some capabilities in an object that is also directly callable, giving succinct access to one preferred way of using it.

I've been working on a strongly-typed composable Redux library where I make augmented functions this way. Although as you can see, I've simply defined my own assign function so I can control the type signature anyway, so I can keep using intersection and you can ignore me! :)