Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Excess properties in object literals are allowed #13444

Closed
johnnyreilly opened this issue Jan 12, 2017 · 4 comments
Closed

Excess properties in object literals are allowed #13444

johnnyreilly opened this issue Jan 12, 2017 · 4 comments
Labels
Duplicate An existing issue was already created

Comments

@johnnyreilly
Copy link

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
Copy link

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
Copy link
Author

johnnyreilly commented Jan 12, 2017

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 RyanCavanaugh added the Duplicate An existing issue was already created label Jan 12, 2017
@RyanCavanaugh
Copy link
Member

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

@johnnyreilly
Copy link
Author

Thanks @RyanCavanaugh - will close as dupe. Hope #12936 happens!

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants