Error when 'extra' properties appear in object literals

[RyanCavanaugh]

What's the Change?

Old Behavior

Prior to 1.6, TypeScript didn't do a good job detecting problems in object literals, especially when the property you tried to specify was optional:

interface TextOptions {
    alignment?: string;
    color?: string;
    padding?: number;
}
function drawText(opts: TextOptions) { ... }

// None of these were errors before
drawText({ align: 'center' }); // Oops
drawText({ colour: 'grey' }); // Oops
drawText({ pading: 32}); // Oops

New Behavior

As of 1.6, properties in object literals that do not have a corresponding property in the type they're being assigned to are flagged as errors:

drawText({ align: 'center' }); // Error, no property 'align' in 'TextOptions'

But I meant to do that

There are a few cases where you may have intended to have extra properties in your object. Depending on what you're doing, there are several appropriate fixes

Type-checking only some properties

Sometimes you want to make sure a few things are present and of the correct type, but intend to have extra properties for whatever reason. Type assertions (<T>v or v as T) do not check for extra properties, so you can use them in place of a type annotation:

interface Options {
    x?: string;
    y?: number;
}

// Error, no property 'z' in 'Options'
let q1: Options = { x: 'foo', y: 32, z: 100 };
// OK
let q2 = <Options>{ x: 'foo', y: 32, z: 100 };
// Still an error (good):
let q3 = <Options>{ x: 100, y: 32, z: 100 };

These properties and maybe more

Some APIs take an object and dynamically iterate over its keys, but have 'special' keys that need to be of a certain type. Adding a string indexer to the type will disable extra property checking

Before

interface Model {
  name: string;
}
function createModel(x: Model) { ... }

// Error
createModel({name: 'hello', length: 100});

After

interface Model {
  name: string;
  [others: string]: any;
}
function createModel(x: Model) { ... }

// OK
createModel({name: 'hello', length: 100});

This is a dog or a cat or a horse, not sure yet

interface Animal { move; }
interface Dog extends Animal { woof; }
interface Cat extends Animal { meow; }
interface Horse extends Animal { neigh; }

let x: Animal;
if(...) {
  x = { move: 'doggy paddle', woof: 'bark' };
} else if(...) {
  x = { move: 'catwalk', meow: 'mrar' };
} else {
  x = { move: 'gallop', neigh: 'wilbur' };
}

Two good solutions come to mind here

Specify a closed set for x

// Removes all errors
let x: Dog|Cat|Horse;

or Type assert each thing

// For each initialization
  x = <Dog>{ move: 'doggy paddle', woof: 'bark' };

This type is sometimes open and sometimes not

A clean solution to the "data model" problem using intersection types:

interface DataModelOptions {
  name?: string;
  id?: number;
}
interface UserProperties {
  [key: string]: any;
}
function createDataModel(model: DataModelOptions & UserProperties) {
 /* ... */
}
// findDataModel can only look up by name or id
function findDataModel(model: DataModelOptions) {
 /* ... */
}
// OK
createDataModel({name: 'my model', favoriteAnimal: 'cat' });
// Error, 'ID' is not correct (should be 'id')
findDataModel({ ID: 32 });

[danquirk]

👍

I would note that traditionally we have tried to keep interfaces and type literals essentially the same from a semantic point of view, which would argue in favor of allowing strict on type literals. I can imagine people wanting to do this on single use options bags with init kind of functions:

function initProgram(url: string, port: number, opts: strict { debugMode: boolean; perfTraces: boolean });

where typeof opts is never re-used so they didn't feel the need to create a named type just for the options.

[JsonFreeman]

Yeah I agree with @danquirk

[ahejlsberg]

It feels like overkill to introduce a whole new kind of type to solve a very confined problem. There are some really counter-intuitive effects around extending and implementing these things, and it isn't clear to me that they could work as type arguments without some sort of "strict" constraint, adding even more complexity.

Perhaps we should consider a simpler and more targeted solution. For example, how about saying that a non-empty type S is not assignable to a type T containing only optional properties if S contains no properties from T. It appears to me this would solve the core problem.

[JsonFreeman]

In particular, I have discussed with @RyanCavanaugh and it seems that strict interfaces have a really weird interaction with intersection types.

[RyanCavanaugh]

It's not just all-optional types, though. Adding one required property to TextOptions only fixes some of the problems:

interface TextOptions {
    text: string;
    alignment?: string;
    color?: string;
    padding?: number;
}
function drawText(opts: TextOptions) { ... }

// No error
drawText({ text: 'foo', align: 'center'} );

// No error
function getDefaultOptions(): TextOptions {
    return { text: 'foo', colour: 'blue'; };
}

// No error
drawText(getDefaultOptions());


// No error
function getDefaultOptions2() {
    return { text: 'foo', colour: 'blue'; };
}
drawText(getDefaultOptions2());

[ahejlsberg]

@RyanCavanaugh I guess there are two ways things go wrong with types that have only optional properties. One is when you accidentally pass a value of a completely unrelated type (i.e. no overlap whatsoever in property names). Another is when you accidentally misspell a property name (but there is some overlap in the remaining properties). I'm not sure which is the more common failure mode, but I have a hunch it is the first one. At least most, if not all, of the issues you link to have examples that fall into that category. So, I'm wondering if we can get there (or get close enough) with just a simple rule.

[JsonFreeman]

It wouldn't be a new kind of type though. It would just be an attribute on an object type that says being assignable to it entails having no extra properties.

That said, it violates the assumption that providing more information about a type makes the type more specific. Our type system assumes that, especially with the new intersection rules.

[RyanCavanaugh]

I'm not sure which is the more common failure mode, but I have a hunch it is the first one.

I think the property names in these examples are only disjoint because people are simplifying their code down to the minimum number of properties required to demonstrate the problem.

In practice, it's very easy to find code in the wild that typos a property name to e.g. $.ajax while getting other property names correct. Specifying timeOut instead of timeout or onfailure instead of onFailure is the kind of thing that slips by casual testing very easily and ought to be caught by a tool that claims to find errors in code.

Arguably we provide more value by catching errors in the non-disjoint case. Providing a completely-wrong object (e.g. forgetting to invoke a function) is usually caught at runtime because it just breaks completely (e.g. no url property means the call fails outright). Having 4 out of 5 properties be correct usually means your code is going to work, but with slightly different semantics than you intended.

Regarding all-optionality, we even have problems with object literals in our own compiler satisfying interfaces with no optional properties at all. There are places where we build an object literal to match some interface (e.g. SymbolDisplayBuilder), but end up including extra things in the object that aren't part of the target type and could have been safely removed. It's not an error per se (it's harmless outside of unmeasurable perf impact), but makes it more difficult for us to identify and remove dead code.

[ahejlsberg]

Ok, here's another idea...

An interesting fact about object literals (and array literals) is that an object reference produced by a literal is known to be the only reference to that object. Thus, when an object literal is assigned to a variable or passed for a parameter of a type with fewer properties than the object literal, we know that information is irretrievably lost. This is a strong indication that something is wrong--probably stronger than the benefits afforded by allowing it.

Now, there are obviously scenarios where this loss of information is expected, for example when a function dynamically inspects an object passed to it (e.g. when object literals are used as maps). But I think we can recognize these situations: The target type would be any, Object, {}, or a type that includes a string or numeric index signature. I think it is highly unlikely to have a target type with actual declared properties and have loss of information be an expected scenario.

So, imagine that an object literal's type is considered "fresh" within the expression in which it occurs, and that we consider it an error to knowingly loose type information from a "fresh" type when the target is not one of the "dynamic" types listed above. This would not only catch the motivating scenarios listed in the introduction, but also the problem Ryan mentions above (where there are no optional properties). Note, BTW, that freshness would be similar in nature to widening of null and undefined: A type would loose it's freshness when we widen it.

[RyanCavanaugh]

A while back I had a prototype that flagged errors on surplus properties on object literals when those literals were contextually typed by a non-empty object type. That seems very close to what you're describing (in terms of behavior I can't identify a difference).

This actually worked quite well. The only meaningful false negative was in one of the RWC suites because someone had a thing like this:

interface Book {
    name: string;
}
interface AudioBook extends Book {
    duration: number;
}
interface PhysicalBook extends Book {
    pages: number;
}

let books: Book[] = [
    { name: 'A', duration: 100 },
    { name: 'B', pages: 40 }
];

This code is only 'correct' under human inspection; I don't see any way to distinguish it from an error since we don't know the universe of Book subtypes. And someone writing this code today might write let books: Array<PhysicalBook|AudioBook> instead, or define interface AnyBook extends Book { [extras: string]: any; }, so it seems like an acceptable break in the name of finding so many other errors.

We'd have to combine that with the "all-optional types require at least one match" rule in order to catch drawText(getDefaultOptions); ?

[ahejlsberg]

Yes, using the contextual type as you describe does indeed seem like it would have the same effect. All up I much prefer this targeted approach to introducing full blown "strict" interfaces.

Not sure about the "all-optional types require at least one match" rule if we do this. I think we should evaluate that one separately.

[corps]

In my experience, this tends to be an exceptional case around interfaces with optional parameters, where as the laxness of type interfaces is super useful most of the time. Golang has a similar problem with their interfaces, and suggests introducing fields to distinguish types if you really need it, although their interface semantics don't have optional attributes in the same way.

Some poor-man's solutions without introducing more language constructs:

interface TextOptionsBag {
    alignment?: string;
    color?: string;
    padding?: number;
}

export interface TextOptions extends TextOptionsBag {
    _isTextOptions: boolean;
}

export function textOptions(options: TextOptionsBag) { return <TextOptions>options };

You could even use a class with a constructor that uses bindings as the interface definition while avoiding excessive optional attributes. Most of the time, optional members on an interface exist to support one main use case: functions with optional parameters.

[JsonFreeman]

@ahejlsberg It is interesting that you are talking about a rule involving optional properties with fresh object types. We have something that works like this today in the subtype relation (but not assignability). Specifically, an unwidened object literal type is not a subtype if it is missing an optional property in the target. My point is that we already have freshness detection for object literals. So we'd just have to add the rule.

@corps Optional parameters have nothing to do with optional properties really. So I wouldn't worry about any loss of expressiveness for optional parameters as a result of this discussion.