Excess properties in object literals are allowed

[johnnyreilly]

TypeScript Version: 2.1.1 / nightly (2.2.0-dev.201xxxxx)

Code

interface TheAllowedProperties { 
 iAmAllowed: boolean;
}

interface TheAllowedPropertiesAndThenSome { 
 iAmAllowed: boolean;
 thenSome: string
}

function doStuff(props: TheAllowedProperties) { 
 // do that thing you do
}

// 1. Errors - yay!!!! So, so very happy
doStuff({
 iAmAllowed: true,
 iAmNot: "surprise!"
})

// 2. Does not error - huh? befuddlement....
const stuffWhatIPreparedEarlier = {
 iAmAllowed: true,
 iAmNot: "surprise!"
};

doStuff(stuffWhatIPreparedEarlier);

// 3. Also does not error - huh? yet more befuddlement....
const moStuff: TheAllowedPropertiesAndThenSome = {
 iAmAllowed: true,
 thenSome: "other data that isn't relevant"
};

doStuff(moStuff);

Expected behavior:
I would have expected the compiler to complain in cases 2 and 3 above as they do in case 1. This might be the same as #7547 but the issue does not appear to be identical and so I wanted to double check. suppressExcessPropertyErrors is false

Actual behavior:
Cases 2 and 3 are not treated as errors.

[mthurlin]

There are many legitimate reasons for allowing "extra" attributes on already existing objects, it would be very annoying if you needed to extract specific attributes in order to pass them around to methods accepting a narrower definition.

However, there are few legitimate reasons for adding extra arguments in an object literal.

A somewhat contrived example:

function getAge(obj: {birthday: number}): number {
 return 2017 - obj.birthday;
}

// Makes sense:
const age = getAge(myUser);

// Make no sense:
const age = getAge({birthday: 1972, name: "Foo"});

[johnnyreilly]

There are many legitimate reasons for allowing "extra" attributes on already existing objects,

Agreed. But there's also legitimate use cases when you want to be stricter about what a function should receive. I should know; I've just encountered this scenario 😄

I was under the misapprehension that the stricter object literal assignment checks that arrived with TypeScript 1.6 extended to the scenarios outlined above. They don't.

I'm just trying to understand if that's intentional and if there's any plans to cater for this in future. (I'm imagining if there was it would be behind a compiler flag.)

[RyanCavanaugh]

It's intentional. See also #3755 / #3823. See #12936 for tracking types which may not have additional members.

[johnnyreilly]

Thanks Ryan Cavanaugh (@RyanCavanaugh) - will close as dupe. Hope #12936 happens!