Mapped type function argument messes up return type

[zamb3zi]

TypeScript Version: nightly (2.2.0-dev.20161203)

Code

const foo = <T>(object: T, partial: Partial<T>) => object;
let o = {a: 5, b: 7};
foo(o, {b: 9}); // ok
o = foo(o, {b: 9}) // error: Type '{ b: number; }' is not 
                   // assignable to type '{ a: number; b: number; }'

Expected behavior:

The return type of the function should be {a: number, b: number}, not {b: number}

Actual behavior:

The presence of a Partial<T> argument causes an incorrect return type. Replacing Partial<T> with {} works around the bug.

[zamb3zi]

I guess T is being inferred from Partial<T> = {b: number} when it should be inferred directly from T = {a: number, b:number}.

[zamb3zi]

I can partly work around the issue using a second type argument but I'm still blocked from creating a properly typed version of Object.assign:

const assign = <T, P extends T>(target: T, ...sources: Array<Partial<P>>): T =>
    Object.assign(target, ...sources);
let o = {a: 5, b: 7};
assign(o, {a: 9}); // ok
assign(o, {a: 9}, {b: 8}); // error: The type argument for type parameter 'P' 
                          // cannot be inferred from the usage. Consider 
                          // specifying the type arguments explicitly.

Breaking it into separate functions works however:

const assign = <T>(target: T) => (...sources: Array<Partial<T>>): T =>
    Object.assign(target, ...sources);
let o = {a: 5, b: 7};
assign(o)({a: 9});         // ok
assign(o)({a: 9}, {b: 8}); // ok

[zamb3zi]

This version does seem to mostly work however:

const assign = <T, P>(target: T, ...sources: Array<Partial<T&P>>): T =>
    Object.assign(target, ...sources);
let o = {a: 5, b: 7};
o = assign(o, {a: 6});                // ok
assign(o, {a: 9}, {b: 8}, {});        // ok
assign(o, {a: 9}, {b: false});        // error
assign(o, {a: 9}, {b: 8}, {x: true}); // error
assign(o, {a: 9}, {b: 8}, 'no');      // ok - why? produces {0: "n", 1: "o", a: 9, b: 8}

Edit: This issue of accepting strings (and other primitives) is tracked in #7485.

[ahejlsberg]

Ideally we'd have a way of indicating that a particular parameter position should not be an inference location (a request that has come up before). That is effectively what happens when you say T & P. Not sure what that would look like though.

Alternatively, we could say that inferences made to mapped types are classified as secondary and would take effect only if no primary inferences are made. We already have the infrastructure in place to do this kind of classification. The downside would be that in cases where we make inferences to say a T and a Readonly<T>, we would ignore the latter inferences even if they were better.

@mhegazy @DanielRosenwasser Opinons?

[ahejlsberg]

I'm thinking that classifying inferences to mapped types as secondary is the right thing to do. My reasoning is that such inferences are (a) more speculative than direct inferences and (b) "lossy" because they drop private and protected properties and call and construct signatures. I will put up a PR.

[DanielRosenwasser]

@ahejlsberg I think making mapped type inferences inferior to those of flat types (like in the PR) is probably the better move. We can see how much of an issue this is if it comes up often and circle back.