Strict object literal assignment checking #3823

ahejlsberg · 2015-07-11T03:35:54Z

This PR implements stricter object literal assignment checks for the purpose of catching excess or misspelled properties. The PR implements the suggestions in #3755. Specifically:

Every object literal is initially considered "fresh".
When a fresh object literal is assigned to a variable or passed for a parameter of a non-empty target type, it is an error for the object literal to specify properties that don't exist in the target type.
Freshness disappears in a type assertion or when the type of an object literal is widened.

Some examples:

var x: { foo: number };
x = { foo: 1, baz: 2 };  // Error, excess property `baz`

var y: { foo: number, bar?: number };
y = { foo: 1, baz: 2 };  // Error, excess or misspelled property `baz`

The rationale for the errors above is that since the fresh types of the object literals are never captured in variables, static knowledge of the excess or misspelled properties should not be silently lost. No errors occur when the fresh types are captured in variables:

var x: { foo: number };
x1 = { foo: 1, baz: 2 };
x = x1;

var y: { foo: number, bar?: number };
y1 = { foo: 1, baz: 2 };
y = y1;

A type can include an index signature to explicitly indicate that excess properties are permitted:

var x: { foo: number, [x: string]: any };
x = { foo: 1, baz: 2 };  // Ok, `baz` matched by index signature

UPDATE 1: This PR also tightens certain parts of the implementation of union types. Specifically:

We no longer perform subtype reduction on union types but instead perform a non-lossy deduplication of the constituent type set.
The process for determining call and constuct signatures of a union type is now less restrictive.
Similar to intersection types, union types now preserve order of the constituent types.

These changes are detailed in the comment thread below.

UPDATE 2: The -suppressExcessPropertyErrors compiler option can be used to disable strict object literal assignment checking. See #4484.

RyanCavanaugh · 2015-07-11T18:20:38Z

tests/baselines/reference/arrayLiteralTypeInference.errors.txt

+    }
+
+    class ActionB extends Action {
+        trueNess: boolean;


I think this should be trueness -- it doesn't look like this test was intended to fail. Another 🏆 for this change's effectiveness.

https://stackoverflow.com/questions/50143250/how-excess-property-check-helps

RyanCavanaugh · 2015-07-11T18:26:19Z

👍 . Pulled it down and tried it out for a while -- behavior seems perfect.

I was trying to find an idiomatic way to remove freshness without casting to any. Going through function identity<T>(x: T): T works but has some runtime impact. Any ideas?

ahejlsberg · 2015-07-12T03:41:02Z

The only way to remove freshness that doesn't generate additional code is a type assertion. I think this is consistent with other situations in which you want to override the type checker. I'm not sure there is a need for a special idiom to defeat the checks associated with freshness.

JsonFreeman · 2015-07-13T02:35:10Z

I agree that a type assertion is a reasonable escape hatch. You also do not have to cast to any, you can cast to a better type if you have one.

JsonFreeman · 2015-07-13T02:43:06Z

src/compiler/types.ts

@@ -1743,10 +1743,12 @@ namespace ts {
        FromSignature           = 0x00040000,  // Created for signature assignment check
        ObjectLiteral           = 0x00080000,  // Originates in an object literal
        /* @internal */
-        ContainsUndefinedOrNull = 0x00100000,  // Type is or contains Undefined or Null type
+        FreshObjectLiteral      = 0x00100000,  // Fresh object literal type


Please define fresh object literal in the comment.

Why do we need a new flag here? This is set in the same place as ObjectLiteral. And when you get the regular type, you turn off FreshObjectLiteral, but not ObjectLiteral, and I don't really understand why. So a regular type is allowed to have excess properties, but it still does not need to have all the optional properties of the target in a subtype check?

Well, it's related to the issue of removing freshness after the first assignment, but still remembering that the source was an object literal. It may be that we can combine the two if we give up on the first assignment bit.

Yup, I think we should give up the first assignment bit. I think it is a strange rule.

So, I don't think we can get rid of the new flag. We use TypeFlag.ObjectLiteral to indicate that a type originated in an object literal and may contain null or undefined types. We can't turn off that flag unless we also widen the type. Yet, in type assertions and during subtype reduction we want to turn off freshness but not widen.

That said, we could still drop the assignment rule. They're really orthogonal issues.

Yes, let's drop the assignment rule.

I understand what you mean about TypeFlags.ObjectLiteral, but I still think we can use it. We actually use ContainsUndefinedOrNull and ContainsObjectLiteral for what you are talking about, not ObjectLiteral directly. For type assertions, I think it's fine to widen, we already do in the downcast direction, and I think it's fine to do it for the upcast (it uses assignability so we should be fine). For creation of a union type, we already give it TypeFlags.Union plus all the widening flags (which do not include ObjectLiteral anyway). So all the flags that getWidenedType checks for would still be there.

So I think it is safe to remove it.

To elaborate about the type assertion case, widening would essentially do two things:

null and undefined become any. They are bottom types anyway, so changing them to any should have no effect.

The object literal is changed with respect to the optional-properties-being-required rule. This rule only applies to subtype, and type assertions use assignability.

I admit it's still possible that I missed something, but if I did, I'd like to understand it before allowing us to have two flags that sound really similar and are easy to confuse.

JsonFreeman · 2015-07-13T03:19:02Z

When we discussed this, we had some thoughts about indexers. Namely if the object type has an indexer, we want to allow excess properties to be provided, since the object might behave as a map. What is the reason for abandoning that idea? Is this going to limit the usefulness of indexers with object literals?

JsonFreeman · 2015-07-13T03:23:55Z

Where is it that an object literal type loses its freshness? I don't see any place in the code where inferring an object type for a variable causes us to infer the regular type.

To clarify, I would assume this "freshness" gets lost when we widen an object literal type. This is what we do to indicate for example that for subtype, optional properties in the target must be declared in the source, unless the source is a "fresh" (unwidened) object literal. So I am looking for similar logic here.

JsonFreeman · 2015-07-13T03:26:39Z

I got my indexer question answered.

JsonFreeman · 2015-07-13T03:27:56Z

src/compiler/checker.ts

+                var resolved = resolveStructuredTypeMembers(type);
+                return !!(resolved.properties.length === 0 ||
+                    resolved.stringIndexType ||
+                    resolved.numberIndexType ||


Ah, so you do these checks on the target side as opposed to when contextually typing the object literal. Actually, this is probably a good thing, because not every assignability check is guaranteed to be accompanied by contextual typing. So if the object did not get contextually typed, the assignment would still be allowed, which is good I think.

But I would add some comments explaining the rationale behind these heuristics.

JsonFreeman · 2015-07-13T18:06:51Z

src/compiler/checker.ts

+                    // Above we check for excess properties with respect to the entire target type. When union
+                    // and intersection types are further deconstructed on the target side, we don't want to
+                    // make the check again (as it might fail for a partial target type). Therefore we obtain
+                    // the regular source type and proceed with that.


Thanks. This makes sense now

danquirk · 2015-07-13T19:41:29Z

Note this is a breaking change. We should probably put this in a widely distributed beta before unleashing it as a default in 1.6 or some future version.

ahejlsberg · 2015-07-13T22:05:33Z

@danquirk Agreed.

sophiajt · 2015-07-13T22:46:27Z

We talked about this a bit today in-person. I'm not sure I'm keen on co-opting object literals to mean this, but I think my real discomfort is that, ideally, interfaces should be able to describe any type. They're the fundamental building block of the type system*.

Because of this, I think the natural place is to describe this first in the interface first. Strictness is opt-in there, and would not break code.

I get that there is a lot of interest in putting this in and catching bugs, but I'm not yet seeing the advantage of taking the breaking change over our philosophy of "interface is the foundation of the type system"

That said, I could be swayed...

- there are a couple corner cases where this isn't true, but arguably we may want to fix those over time.

BREAKING CHANGE: Reasons: 1) Interfaces should not start with letter ‘I’ 2) Interfaces do not help with mistype properties, but literal types do. - microsoft/TypeScript#3823 - https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#strict-object-literal-assignment-checking

TS 1.6 requires that object literals assigned to variables or parameters with an interface typing may only contain properties that are listed in the interface. See microsoft/TypeScript#3823 for details. This mostly affected React component props interfaces which did not extend react.Props so were missing the common key, ref and children props.

ahejlsberg added 3 commits July 8, 2015 19:04

Object literals can only have properties that exist in contextual type

cd0d3ba

Switch to assignability check and fix compiler bugs found by check

11aecee

Accepting new baselines

3fe7591

msftclas added the cla-not-required label Jul 11, 2015

Support union and intersection types in checks

f57991e

ahejlsberg mentioned this pull request Jul 11, 2015

Error when 'extra' properties appear in object literals #3755

Closed

RyanCavanaugh reviewed Jul 11, 2015
View reviewed changes

JsonFreeman reviewed Jul 13, 2015
View reviewed changes

Addressing CR feedback

aa26980

JsonFreeman reviewed Jul 13, 2015
View reviewed changes

ahejlsberg added 3 commits July 13, 2015 11:15

Ignore freshness in subtype reduction / Treat Object as {}

d78fa18

Fixing bug in test

2eca3d5

Accepting new baselines

c7b0732

jbondc mentioned this pull request Aug 18, 2015

What do we do about object literals that make use of structural subtyping in 1.6? #4234

Closed

This was referenced Aug 27, 2015

Adding -suppressExcessPropertyErrors compiler option #4484

Merged

Union subtype reduction #4537

Merged

mhegazy mentioned this pull request Sep 3, 2015

Union of function signatures cannot be invoked because it lacks a call signature #4612

Closed

Kuniwak mentioned this pull request Sep 3, 2015

CI failure on TypeScript 1.6 Beta palantir/tslint#634

Closed

kimamula mentioned this pull request Sep 6, 2015

add Event3 and Event4 kimamula/ts-eventemitter#1

Closed

jods4 mentioned this pull request Sep 8, 2015

TS 1.6: strict object literal assignment aurelia/router#208

Closed

fredgalvao mentioned this pull request Sep 20, 2015

Make definitions work nicely with third-party promise implementations AGBrown/pouchdb.d.ts#18

Closed

kitsonk mentioned this pull request Dec 20, 2015

problem with interfaces #6175

Closed

ewinslow mentioned this pull request Jan 5, 2016

Stricter interfaces/literal types #6352

Closed

yortus mentioned this pull request Feb 8, 2016

Typescript: Pass an extra parameter #6963

Closed

malibuzios mentioned this pull request May 19, 2016

show error when use difference two way call function. #8682

Closed

RyanCavanaugh mentioned this pull request Jan 12, 2017

Excess properties in object literals are allowed #13444

Closed

This was referenced Feb 28, 2017

Typed 'this' in object literal methods #14141

Merged

Possible bug: Hybrid between two interfaces of a union passes type checking #14383

Closed

RyanCavanaugh mentioned this pull request Mar 10, 2017

Unexpected behavior for "keyof" type-check #14576

Closed

ahejlsberg mentioned this pull request Mar 12, 2017

Empty interface allow any object? #14606

Closed

olegdunkan mentioned this pull request Sep 10, 2017

[BUG] Issue with union and literal types #18365

Closed

kitsonk mentioned this pull request Oct 25, 2017

Tuple types accepting incorrect data #19463

Closed

jdmunro mentioned this pull request Mar 29, 2018

Function unexpectedly allows returning arguments object directly if it's a superset of the return type #22982

Closed

RyanCavanaugh mentioned this pull request May 21, 2018

Index signature pointing to any is too relaxed #24083

Closed

microsoft locked and limited conversation to collaborators Jul 31, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Strict object literal assignment checking #3823

Strict object literal assignment checking #3823

ahejlsberg commented Jul 11, 2015

RyanCavanaugh Jul 11, 2015

shamhub May 2, 2018

RyanCavanaugh commented Jul 11, 2015

ahejlsberg commented Jul 12, 2015

JsonFreeman commented Jul 13, 2015

JsonFreeman Jul 13, 2015

JsonFreeman Jul 13, 2015

ahejlsberg Jul 13, 2015

JsonFreeman Jul 13, 2015

ahejlsberg Jul 13, 2015

JsonFreeman Jul 14, 2015

JsonFreeman Jul 14, 2015

JsonFreeman Jul 14, 2015

JsonFreeman commented Jul 13, 2015

JsonFreeman commented Jul 13, 2015

JsonFreeman commented Jul 13, 2015

JsonFreeman Jul 13, 2015

JsonFreeman Jul 13, 2015

JsonFreeman Jul 13, 2015

danquirk commented Jul 13, 2015

ahejlsberg commented Jul 13, 2015

sophiajt commented Jul 13, 2015

Strict object literal assignment checking #3823

Strict object literal assignment checking #3823

Conversation

ahejlsberg commented Jul 11, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RyanCavanaugh commented Jul 11, 2015

ahejlsberg commented Jul 12, 2015

JsonFreeman commented Jul 13, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JsonFreeman commented Jul 13, 2015

JsonFreeman commented Jul 13, 2015

JsonFreeman commented Jul 13, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danquirk commented Jul 13, 2015

ahejlsberg commented Jul 13, 2015

sophiajt commented Jul 13, 2015