show error when use difference two way call function.

[captainhamid]

I use typescript version 1.8 (but this problem, there was Previous version and now version)
problem: show error when use difference two way call function.

interface SquareConfig {
  color?: string;
  width?: number;
}

function createSquare(config: SquareConfig): {color: string; area: number} {
  var newSquare = {color: "white", area: 100};
  if (config.color) {
    newSquare.color = config.color;
  }
  if (config.width) {
    newSquare.area = config.width * config.width;
  }
  return newSquare;
}

two way call function and to reply
1.

var obj = {color1: "black"};
var mySquare = createSquare(obj);

is correct work
but
2.

var mySquare = createSquare({color1: "black"});

above code produce error.

error TS2345: Argument of type '{ color1: string; }' is not assignable to parameter of type 'SquareConfig'.
Object literal may only specify known properties, and 'color1' does not exist in type 'SquareConfig'.

[malibuzios]

This seems like the effect of strict object literal assignment checking, introduced in TypeScript 1.6. It means that for the config parameter, only a literal containing the exact set of properties is allowed (optional properties are still optional). This restriction does not apply however when a non-literal, like a variable is passed to it. The reasoning for this is explained in the issue.

If the intention here is to allow additional properties on object literals when assigned to SquareConfig, an index signature can be added to the interface:

interface SquareConfig {
    color?: string;
    width?: number;
    [propName: string]: any;
}

I also wanted to mention that due to a 'bug' in the language (which I personally see as severe), somewhat 'ironically' these assignments still work:

interface SquareConfig {
  color?: string;
  width?: number;
}

let x: SquareConfig = {};

x = 1234; // no error
x = "hello"; // no error
x = true; // no error

(adding the index signature would incidentally help prevent these, so it may provide somewhat of a partial workaround, but that's quite unrelated)

[RyanCavanaugh]

#7485 covers the fact that we ought to error in case 2.