Object spread #11150

sandersn · 2016-09-26T16:59:03Z

Leaves #10727 still open
Fixes #2103
Leaves #11100 still open

Important Update

The PR no longer contains a spread type, only spread syntax, which creates object types. I expect a spread type or something similar to be available in future versions of TypeScript.

Updates to proposed semantics: type variable assignability

A spread type containing spread elements whose types are type variables is assignable to another spread type also containing type variables if the non-type-variable properties and index signatures are assignable as above and the the type variables are the same variables in the same order.

For example: { a: number, ...T, b: number, ...U, ...x } is assignable to { b: number, a: number, ...x ...T, ...U} and vice versa. But the similar { a: number, ...T, b: number, ...U, ...x } is not assignable to { b: number, a: number, ...x ...U, ...T} because the order of T and U is reversed.

This rule is not strictly safe, since a type parameter could override any properties that precede it (see the rule for private below), but it would be odd if { ...T, ...U } were not assignable to { ...T, ...U }. Instead, this rule assumes that the contents of a type variable will not conflict with other properties.

Important Implementation Details

Spread types use a binary representation to make recursive transformations easier. This matches the proposal but the syntax remains close to spread's expression syntax.

getSpreadType creates a spread only if the spread type contains a type parameter. Otherwise it will create an anonymous type, or union or intersection of anonymous types. The binary structure is left deep, so the left side of a spread type is either another spread (the recursive case) or an object type (the terminal case). The right side of spread type is either a type parameter or an object type. Adjacent object types are spread into a single object type, so the structure will never have two adjacent object types, only adjacent type parameters.

Updated proposal

The spread part of #10727's updated proposal follows for convenience:

The spread type is a new type operator that types the TC39 stage 3 object spread operator. Its counterpart, the difference type, will type the proposed object rest destructuring operator. The spread type { ...A, ...B } combines the properties, but not the call or construct signatures, of entities A and B.

The original issue for spread/rest types is #2103. Note that this proposal deviates from the specification by keeping all properties except methods, not just own enumerable ones.

Proposal syntax

The type syntax in this proposal differs from the type syntax as implemented in order to treat spread as a binary operator. Three rules are needed to convert the { ...spread } syntax to binary syntax spread1 ... spread2.

{ ...spread } becomes {} ... spread.
{ a, b, c, ...d} becomes {a, b, c} ... d
Multiple spreads inside an object literal are treated as sequences of binary spreads: { a, b, c, ...d, ...e, f, g} becomes {a, b, c} ... d ... e ... { f, g }.

Type Relationships

Identity: {} ... A is equivalent to the properties of A. A ... A ... A is equivalent to A ... A and A ... A is equivalent to {} ... A.
Commutativity: A ... B is not equivalent to B ... A. Properties of B overwrite properties of A with the same name.
Associativity: (A ... B) ... C is equivalent to A ... (B ... C). ... is right-associative.
Distributivity: Spread is distribute over both | and &, so A ... (B | C) is equivalent to A ... B | A ... C and A ... (B & C) is equivalent to A ... B & A ... C.

Assignment compatibility

A ... B is assignable to X if the properties and index signatures of A ... B are assignable to those of X, and X has no call or construct signatures.
X is assignable to A ... B if the properties and index signatures of X are assignable to those of A ... B.

Type variables

A spread type containing type parameters is assignable to another spread type if the the non-type-variable properties and index signatures are assignable as above and the type variables are the same variables in the same order.

For example: { a: number, b: number } ... T is assignable to { a: number } ...T and to T ... { a: number }. But the similar T ... U is not assignable to U ... T because the order of T and U is reversed.

Type inference

Type inference is allowed between an object type source and a spread type target with a type parameter as either the left or right side. If the type parameter is on the right, then its inferred type is the whole source type. If the type parameter is on the left, then its inferred type is the source type minus properties on the right side of the spread.

For example, if the target is T ... { a: number } and the source is { a: number, b: string }, the inferred type for T is { b: string }. Because spread types remove call and construct signatures, if the source were { a: number, b: string, (): void }, the type inferred for T would still be { b: string }.

Properties and index signatures

In the following definitions, 'property' means either a property or a get accessor.

The type A ... B has a property P if A has a property P or B has a property P. In this case (A ... B).P has the type

Of B.P if B.P is not optional.
Of A.P | B.P if B.P is optional and A has a property P.
Of A.P otherwise.

Index signatures spread the same way as properties.

private, protected and readonly behave the same way as optionality except that if A.P or B.P is private, protected or readonly, then (A ...B).P is private, protected or readonly, respectively.

Call and Construct signatures

A ... B has no call signatures and no construct signatures, since these are not properties.

Precedence

Precedence of ... is higher than & and |. Since the language syntax is that of object type literals, precedence doesn't matter since the braces act as boundaries of the spread type.

Examples

Taken from the TC39 proposal and given types.

Shallow Clone (excluding prototype)

let aClone: { ...A } = { ...a };

Merging Two Objects

let ab: { ...A, ...B } = { ...a, ...b };

Overriding Properties

let aWithOverrides: { ...A, x: number, y: number } = { ...a, x: 1, y: 2 };
// equivalent to
let aWithOverrides: { ...A, ...{ x: number, y: number } } = { ...a, ...{ x: 1, y: 2 } };

Default Properties

let aWithDefaults: { x: number, y: number, ...A } = { x: 1, y: 2, ...a };

Multiple Merges

// Note: getters on a are executed twice
let xyWithAandB: { x: number, ...A, y: number, ...B, ...A } = { x: 1, ...a, y: 2, ...b, ...a };
// equivalent to
let xyWithAandB: { x: number, y: number, ...B, ...A } = { x: 1, ...a, y: 2, ...b, ...a };

Getters on the Object Initializer

// Does not throw because .x isn't evaluated yet. It's defined.
let aWithXGetter: { ...A, x: never } = { ...a, get x() { throw new Error('not thrown yet') } };

Getters in the Spread Object

// Throws because the .x property of the inner object is evaluated when the
// property value is copied over to the surrounding object initializer.
let runtimeError: { ...A, x: never } = { ...a, ...{ get x() { throw new Error('thrown now') } } };

Setters Are Not Executed When They're Redefined

let z: { x: number } = { set x() { throw new Error(); }, ...{ x: 1 } }; // No error

Null/Undefined Are Ignored

let emptyObject: {} = { ...null, ...undefined }; // no runtime error

Updating Deep Immutable Object

let newVersion: { ...A, name: string, address: { address, zipCode: string }, items: { title: string }[] } = {
  ...previousVersion,
  name: 'New Name', // Override the name property
  address: { ...previousVersion.address, zipCode: '99999' } // Update nested zip code
  items: [...previousVersion.items, { title: 'New Item' }] // Add an item to the list of items
};

Note: If A = { name: string, address: { address, zipCode: string }, items: { title: string }[] }, then the type of newVersion is equivalent to A

sandersn · 2016-09-26T17:25:50Z

@ahejlsberg can you take a look?

1. SpreadElementExpression (existing, for arrays) -> SpreadExpression 2. SpreadElement (new for object literals) -> SpreadElementExpression

What's YOUR favourite thing about Mars, Beartato?

Previously, they worked when they came from a spread type but not when written in the object literal itself.

As elsewhere in the compiler code

DanielRosenwasser · 2016-09-28T21:34:30Z

Identity

Is { ...number } equivalent to number? I don't think that it should be.

sandersn · 2016-09-28T21:42:34Z

What are the properties of number? I don't think there are any, so { ... number } is equivalent to {}, which is the properties of number.

This is based on experimentation with V8's implementation of Object.assign, where Object.assign({}, 12) returns {}.

DanielRosenwasser · 2016-09-28T21:54:33Z

What are the properties of number? I don't think there are any,

Well....

Usually when we think about the properties of number, we think of its apparent type Number. In the spec, before getting the property keys, the ToObject function is used on whatever value you're spreading in. So there's precedent for the same analogue here: to get the properties of number, we get the properties of Number.

However, you're right that the "correct" behavior will give you no properties because none of the properties of Number are "owned" by any instance. So it would be "wrong" to give that to users, though I can't imagine who would ever do that anyway.

DanielRosenwasser

Some intermediate feedback.

DanielRosenwasser · 2016-09-28T22:16:23Z

src/compiler/checker.ts

@@ -4273,6 +4319,21 @@ namespace ts {
            setObjectTypeMembers(type, emptySymbols, callSignatures, constructSignatures, stringIndexInfo, numberIndexInfo);
        }

+        function resolveSpreadTypeMembers(type: SpreadType) {
+            // The members and properties collections are empty for spread types. To get all properties of an


Looks like this should be JSDoc.

This code no longer exists.

DanielRosenwasser · 2016-09-28T22:17:35Z

src/compiler/checker.ts

+            // spread type use getPropertiesOfType.
+            let stringIndexInfo: IndexInfo = getIndexInfoOfSymbol(type.symbol, IndexKind.String);
+            let numberIndexInfo: IndexInfo = getIndexInfoOfSymbol(type.symbol, IndexKind.Number);
+            for (let i = type.types.length - 1; i > -1; i--) {


This code no longer exists.

DanielRosenwasser · 2016-09-28T22:18:22Z

src/compiler/types.ts

-    export interface IntersectionType extends UnionOrIntersectionType { }
+    /* @internal */
+    export interface SpreadElementType extends ResolvedType {
+        isDeclaredProperty?: boolean;


Can you add documentation about what this means?

This type no longer exists. getSpreadType acts on this information immediately instead of preserving it.

DanielRosenwasser · 2016-09-28T22:23:01Z

src/compiler/checker.ts

@@ -5589,15 +5729,67 @@ namespace ts {
        function getTypeFromTypeLiteralOrFunctionOrConstructorTypeNode(node: Node, aliasSymbol?: Symbol, aliasTypeArguments?: Type[]): Type {
            const links = getNodeLinks(node);
            if (!links.resolvedType) {
-                // Deferred resolution of members is handled by resolveObjectTypeMembers
-                const type = createObjectType(TypeFlags.Anonymous, node.symbol);
+                const isSpread = (node.kind === SyntaxKind.TypeLiteral &&


hasSpread

Is there an isTypeLiteral s that you don't have to subsequently cast?

No, but it only saves a couple of casts anyway.

DanielRosenwasser · 2016-09-28T22:24:55Z

src/compiler/checker.ts

+                const isSpread = (node.kind === SyntaxKind.TypeLiteral &&
+                                  find((node as TypeLiteralNode).members, elt => elt.kind === SyntaxKind.SpreadTypeElement));
+                let type: ObjectType;
+                if (isSpread) {


Consider refactoring the entire body here into its own function to keep it clean.

Good idea. Done.

DanielRosenwasser · 2016-09-28T22:26:28Z

src/compiler/checker.ts

-                const type = createObjectType(TypeFlags.Anonymous, node.symbol);
+                const isSpread = (node.kind === SyntaxKind.TypeLiteral &&
+                                  find((node as TypeLiteralNode).members, elt => elt.kind === SyntaxKind.SpreadTypeElement));
+                let type: ObjectType;


You never use type in the first branch, so do you really need to declare it up here?

DanielRosenwasser · 2016-11-03T19:54:45Z

src/compiler/checker.ts

@@ -5851,6 +5879,67 @@ namespace ts {
            return links.resolvedType;
        }

+        /**
+         * Since the source of spread types are object literals and type literals, which are not binary,


Not type literals anymore

DanielRosenwasser · 2016-11-03T20:05:21Z

src/compiler/checker.ts

+                }
+                else if (!(rightProp.flags & SymbolFlags.Method && isFromSpread) &&
+                         !(rightProp.flags & SymbolFlags.SetAccessor && !(rightProp.flags & SymbolFlags.GetAccessor))) {
+                    // skip methods from spreads and accessors with setters but no getters


Why accessors with setters & no getters? Is this per spec?

From offline, "hilariously yes"
.

DanielRosenwasser · 2016-11-04T18:24:39Z

src/compiler/checker.ts

+            let stringIndexInfo: IndexInfo;
+            let numberIndexInfo: IndexInfo;
+            if (left === emptyObjectType) {
+                // for the first spread element, left === emptyObjectType, so take the right's string indexer


What if the right element is an empty object?

It's treated like any other object type. emptyObjectType is only a marker of the start of the spread type because the checkObjectLiteral uses getSpreadType in a left fold manner, and emptyObjectType is initial value of the fold.

DanielRosenwasser · 2016-11-04T18:27:09Z

src/compiler/checker.ts

+                    || leftProp.name in skippedPrivateMembers) {
+                    continue;
+                }
+                if (leftProp.name in members) {


It sounds like members should be renamed to rightProps

Well, it's the members of the resulting spread. If right doesn't have a property that left does, then members will have leftProp. So calling it rightProps is not accurate.

DanielRosenwasser · 2016-11-07T18:40:24Z

src/compiler/checker.ts

            result.isReadonly = isReadonly;
-            result.type = containingType.flags & TypeFlags.Union ? getUnionType(propTypes) : getIntersectionType(propTypes);
+            result.type = containingType.flags & TypeFlags.Intersection ? getIntersectionType(propTypes) : getUnionType(propTypes);


Revert If you feel like it

This avoids the need for a synthetic symbol and later code called from getTypeOfSymbol.

ahejlsberg · 2016-11-07T20:47:31Z

src/compiler/checker.ts

@@ -3564,6 +3571,14 @@ namespace ts {
            return unknownType;
        }

+        function getTypeOfSpreadProperty(symbol: Symbol) {


I don't think there's a need for a new kind of symbol. We should just create regular SymbolFlags.Property symbols and compute the type eagerly.

ahejlsberg · 2016-11-07T20:49:29Z

src/compiler/checker.ts

+            if (type.flags & TypeFlags.UnionOrIntersection) {
+                return getPropertiesOfUnionOrIntersectionType(<UnionType>type);
+            }
+            return getPropertiesOfObjectType(type);


Why this change? I much prefer the existing terser functional style.

With a separate spread type, I had more code in here that made the verbose style more readable. Restored.

ahejlsberg · 2016-11-07T20:51:52Z

src/compiler/checker.ts

            result.containingType = containingType;
            result.hasNonUniformType = hasNonUniformType;
            result.isPartial = isPartial;
            result.declarations = declarations;
+            if (declarations.length) {
+                result.valueDeclaration = declarations[0];
+            }


Why was this added? I don't think it is correct to say the first of an arbitrarily ordered list is the definitely value declaration. Plus, the declaration doesn't actually correctly reflect the type of the union property.

Checking index constraints in checkIndexConstraints relies on valueDeclaration. It's not needed now that we don't create synthetic symbols for spread any more, so I removed it. But in general checkIndexConstraints works on synthetic properties by mistake. If choosing an arbitrary valueDeclaration isn't right, the checkIndexConstraints needs to stop relying on it.

ahejlsberg · 2016-11-07T20:52:20Z

src/compiler/checker.ts

@@ -5041,7 +5069,7 @@ namespace ts {
            const declaration = getIndexDeclarationOfSymbol(symbol, kind);
            if (declaration) {
                return createIndexInfo(declaration.type ? getTypeFromTypeNode(declaration.type) : anyType,
-                    (getModifierFlags(declaration) & ModifierFlags.Readonly) !== 0, declaration);
+                                       (getModifierFlags(declaration) & ModifierFlags.Readonly) !== 0, declaration);


We usually don't indent like this.

ahejlsberg · 2016-11-07T20:58:21Z

src/compiler/checker.ts

+         * and right = the new element to be spread.
+         */
+        function getSpreadType(left: Type, right: Type, symbol: Symbol): ResolvedType | IntrinsicType {
+            Debug.assert(!!(left.flags & (TypeFlags.Object | TypeFlags.Any)) && !!(right.flags & (TypeFlags.Object | TypeFlags.Any)), "Only object types may be spread.");


Did you consider permitting intersection types as well? I understand how union types are harder and would require "lifting" to produce a resulting union type, but it seems like intersections would just work.

I did, and it would be simple to restore the code I had there earlier. The reason I decided against is that it gets harder to issue a correct, understandable error in checkObjectLiteral because intersections that contain type parameters are still not allowed. And I assume that we'll have a good story for all kinds of type operators shortly after 2.1 ships, so a restriction on intersections won't have lasting problems.

ahejlsberg · 2016-11-07T21:25:58Z

src/compiler/checker.ts

+                        result.declarations = declarations;
+                        if (declarations.length) {
+                            result.valueDeclaration = declarations[0];
+                        }


Again, any reason you're setting the valueDeclaration property?

Same as above. Removed.

ahejlsberg · 2016-11-07T21:26:32Z

src/compiler/checker.ts

+                            result.valueDeclaration = declarations[0];
+                        }
+                        result.isReadonly = isReadonlySymbol(leftProp) || isReadonlySymbol(rightProp);
+                        members[leftProp.name] = result;


Just compute the type here and set it directly on the new symbol.

ahejlsberg · 2016-11-07T21:29:00Z

src/compiler/checker.ts

-                checkIndexConstraints(type);
-                checkTypeForDuplicateIndexSignatures(node);
-                checkObjectTypeForDuplicateDeclarations(node);
+                if (type.flags & TypeFlags.Object) {


When would this not be an object?

Left over from when { ...T } syntax would produce a spread type. Removed.

ahejlsberg · 2016-11-07T21:30:05Z

src/compiler/checker.ts

@@ -17140,7 +17270,7 @@ namespace ts {
                // perform property check if property or indexer is declared in 'type'
                // this allows to rule out cases when both property and indexer are inherited from the base class
                let errorNode: Node;
-                if (prop.valueDeclaration.name.kind === SyntaxKind.ComputedPropertyName || prop.parent === containingType.symbol) {
+                    if (prop.valueDeclaration.name.kind === SyntaxKind.ComputedPropertyName || prop.parent === containingType.symbol) {


Restore indentation.

ahejlsberg · 2016-11-07T21:31:43Z

src/compiler/checker.ts

                const name = prop.name;
-                if (name.kind === SyntaxKind.ComputedPropertyName) {
+                if (name && name.kind === SyntaxKind.ComputedPropertyName) {


Can name now be undefined where previously it couldn't?

Not anymore. Removed.

Instead of getSpreadType. Also clean up special-case handling inside getSpreadType to be more readable.

sandersn

Addressed PR comments

sandersn · 2016-11-07T21:42:56Z

src/compiler/checker.ts

+            if (type.flags & TypeFlags.UnionOrIntersection) {
+                return getPropertiesOfUnionOrIntersectionType(<UnionType>type);
+            }
+            return getPropertiesOfObjectType(type);


With a separate spread type, I had more code in here that made the verbose style more readable. Restored.

sandersn · 2016-11-07T21:43:34Z

src/compiler/checker.ts

@@ -5041,7 +5069,7 @@ namespace ts {
            const declaration = getIndexDeclarationOfSymbol(symbol, kind);
            if (declaration) {
                return createIndexInfo(declaration.type ? getTypeFromTypeNode(declaration.type) : anyType,
-                    (getModifierFlags(declaration) & ModifierFlags.Readonly) !== 0, declaration);
+                                       (getModifierFlags(declaration) & ModifierFlags.Readonly) !== 0, declaration);


sandersn · 2016-11-07T21:43:58Z

src/compiler/checker.ts

+                            result.valueDeclaration = declarations[0];
+                        }
+                        result.isReadonly = isReadonlySymbol(leftProp) || isReadonlySymbol(rightProp);
+                        members[leftProp.name] = result;


sandersn · 2016-11-07T21:46:33Z

src/compiler/checker.ts

-                checkIndexConstraints(type);
-                checkTypeForDuplicateIndexSignatures(node);
-                checkObjectTypeForDuplicateDeclarations(node);
+                if (type.flags & TypeFlags.Object) {


Left over from when { ...T } syntax would produce a spread type. Removed.

sandersn · 2016-11-07T21:51:01Z

src/compiler/checker.ts

            result.containingType = containingType;
            result.hasNonUniformType = hasNonUniformType;
            result.isPartial = isPartial;
            result.declarations = declarations;
+            if (declarations.length) {
+                result.valueDeclaration = declarations[0];
+            }


Checking index constraints in checkIndexConstraints relies on valueDeclaration. It's not needed now that we don't create synthetic symbols for spread any more, so I removed it. But in general checkIndexConstraints works on synthetic properties by mistake. If choosing an arbitrary valueDeclaration isn't right, the checkIndexConstraints needs to stop relying on it.

sandersn · 2016-11-07T21:51:17Z

src/compiler/checker.ts

+                        result.declarations = declarations;
+                        if (declarations.length) {
+                            result.valueDeclaration = declarations[0];
+                        }


Same as above. Removed.

sandersn · 2016-11-07T21:52:07Z

src/compiler/checker.ts

@@ -17140,7 +17270,7 @@ namespace ts {
                // perform property check if property or indexer is declared in 'type'
                // this allows to rule out cases when both property and indexer are inherited from the base class
                let errorNode: Node;
-                if (prop.valueDeclaration.name.kind === SyntaxKind.ComputedPropertyName || prop.parent === containingType.symbol) {
+                    if (prop.valueDeclaration.name.kind === SyntaxKind.ComputedPropertyName || prop.parent === containingType.symbol) {


sandersn · 2016-11-07T21:56:56Z

src/compiler/checker.ts

                const name = prop.name;
-                if (name.kind === SyntaxKind.ComputedPropertyName) {
+                if (name && name.kind === SyntaxKind.ComputedPropertyName) {


Not anymore. Removed.

sandersn · 2016-11-07T23:34:28Z

I just noticed that I forgot to comment on not allowing intersections. Here's the comment copied out of the original thread since github's UI collapses that one.

Did you consider permitting intersection types as well? I understand how union types are harder and would require "lifting" to produce a resulting union type, but it seems like intersections would just work.

I did, and it would be simple to restore the code I had there earlier. The reason I decided against is that it gets harder to issue a correct, understandable error in checkObjectLiteral because intersections that contain type parameters are still not allowed. And I assume that we'll have a good story for all kinds of type operators shortly after 2.1 ships, so a restriction on intersections won't have lasting problems.

Previously array destructuring inside an object destructuring with an object rest would downlevel the array destructuring to ES5. This breaks if the code that targets ES2015 is using iterators instead of arrays since iterators don't support [0] or .slice that the ES5 emit uses.

Now with object destructuring inside array destructuring inside object destructuring! Each with their own array/object rest! Also updates baselines.

ahejlsberg · 2016-11-09T18:38:31Z

src/compiler/checker.ts

@@ -4512,7 +4523,7 @@ namespace ts {
                t;
        }

-        function createUnionOrIntersectionProperty(containingType: UnionOrIntersectionType, name: string): Symbol {
+        function createUnionOrIntersectionProperty(containingType: UnionOrIntersectionType, name: string) {


Why remove the return type annotation?

No reason. Fixed.

ahejlsberg · 2016-11-09T20:44:05Z

src/compiler/checker.ts

+                }
+                if (leftProp.name in members) {
+                    const rightProp = members[leftProp.name];
+                    if (rightProp.flags & SymbolFlags.Optional) {


I think a more correct check here is whether the type of rightProp includes undefined. After all, that's how it works at runtime.

Done. I had to keep the optionality check for when strict null checks is off.

Object rest

wclr · 2016-11-22T15:15:27Z

Is it possible to omit a property from object?

MathieuLorber · 2016-11-22T16:28:12Z

@whitecolor no, compiler complains

Thanks a lot for that feature, it at least saved my life \o/

alitaheri · 2016-11-22T16:53:47Z

@whitecolor

you mean:

const myObj = {a: 1, b:2, c:3};
const { a, ...myObjWithoutA} = myObj;

// myObjWithoutA has b and c but not a

wclr · 2016-11-22T17:21:21Z

@alitaheri that is intresting btw, thanks

What I meant a little bit different, though I probably do not refere to spread,

I wanted to make it with only types without objects

say from interface {a: string, b: string} get => interface {b: string}

MathieuLorber · 2016-11-22T17:28:22Z

@whitecolor it isn't relative to spread, from what I understand now. I first understood your question was relative to smthg like that :

interface FooBar {
    foo: string
    bar: string
}
let val = {foo: 'hello'};
let val2: FooBar = {...val};

In that configuration, compiler complains.

uxp · 2016-12-22T20:39:04Z

I was looking to implement the emitted code from this patch into my project as a 'backport' utility until we can update to a released Typescript version that contains this operator, but I think I'm not understanding exactly what the patch does, because the way it seems to be implemented might have a bug?

Basically, if we look at the emitted code in isolation, the idea of what it's supposed to do is fairly obvious.

 +        const restHelper = `
 +var __rest = (this && this.__rest) || function (s, e) {
 +    var t = {};
 +    for (var p in s) if (Object.prototype.hasOwnProperty.call(s, p) && !e.indexOf(p))
 +        t[p] = s[p];
 +    return t;
 +};`;

Create new target object t, and for every owned property p of source s that is not specified as excluded in e, copy s's property p to t, and then return target object t.

The only problem with this specifically is that javascript arrays are zero indexed, and the value of the expression !0 is true, so a literal invocation of this function with a source object of { a: 1, b: 2, c: 3, d: 4, e: 5 } such as:

let obj = { a: 1, b: 2, c: 3, d: 4, e: 5 };
let { a, b, c } = obj;
let rest = __rest(obj, ['a', 'b', 'c']);

would result in the rest variable containing the values { a: 1, d: 4, e: 5 }. I would expect the result to lack the keys a, b, and c, but it manages to include a, since it's index in the parameter array e is not greater than zero. In order to accomplish this desire, we could check to see if the index of the excluded key is -1, as that is the value that is returned from the indexOf() function when the value does not exist.

Unless I'm (likely) missing some essential context, it seems to me that there is an issue with the accepted solution.

Thanks for your time.

normalser · 2016-12-22T21:45:00Z

@uxp - works fine in latest / playground #12956 FYI

sandersn added 6 commits September 26, 2016 09:30

Parse, bind and check spread types and elements

a3ffe6f

Declaration emit spread types and downlevel spread

7004652

Update build files

bf866ce

Add spread tests

0fea59f

Update baselines

c8db211

Move interfaceSpread to correct location

3938559

msftclas added the cla-not-required label Sep 26, 2016

Object.assign uses spread types now

63f8c99

sandersn added 9 commits September 26, 2016 11:50

Rename Spread[Element]Expression

a0db197

1. SpreadElementExpression (existing, for arrays) -> SpreadExpression 2. SpreadElement (new for object literals) -> SpreadElementExpression

Change new file to use CRLF

9a7ebb0

What's YOUR favourite thing about Mars, Beartato?

Make index signatures work on spread types

cfdf751

Previously, they worked when they came from a spread type but not when written in the object literal itself.

Test spread type index signatures

d6e414c

Union multiple spread index signatures

429b0d9

Test object spread index signatures

78420ad

Spreads w/a single type parameter assignable to that type parameter

7e7a26a

Add object spread scenario tests

0f773c5

Merge branch 'master' into object-spread

484e66f

sandersn mentioned this pull request Sep 28, 2016

Add spread/rest higher-order types operator #10727

Open

isDeclaredProperty: Use optional-boolean idiom

62c5bda

As elsewhere in the compiler code

DanielRosenwasser requested changes Sep 28, 2016

View reviewed changes

minedeljkovic mentioned this pull request Sep 29, 2016

TypeScript version minedeljkovic/redux-elmish#1

Open

sandersn added 5 commits September 29, 2016 11:02

Merge branch 'master' into object-spread

05ef9dd

Update object spread scenarios test

b9af986

Merge branch 'master' into object-spread

d4e910f

Add more generic assignability cases

57850ec

Merge branch 'master' into object-spread

cec3a37

DanielRosenwasser reviewed Nov 7, 2016

View reviewed changes

sandersn added 5 commits November 7, 2016 11:00

Revert unneeded change and comments per PR

83e95d4

Merge branch 'master' into object-spread

f03fecb

Merge branch 'object-spread' into object-rest

609cd00

Do not emit __rest for --target esnext

9977936

Create spread property types eagerly

567f563

This avoids the need for a synthetic symbol and later code called from getTypeOfSymbol.

ahejlsberg requested changes Nov 7, 2016

View reviewed changes

sandersn added 2 commits November 7, 2016 13:35

Set spread type symbols in checkObjectLiteral

bd5ce28

Instead of getSpreadType. Also clean up special-case handling inside getSpreadType to be more readable.

Address more PR comments

e1c50e1

sandersn commented Nov 7, 2016

View reviewed changes

sandersn added 2 commits November 9, 2016 10:47

Improve nested destructuring test for ESNext emit

0196947

Now with object destructuring inside array destructuring inside object destructuring! Each with their own array/object rest! Also updates baselines.

ahejlsberg reviewed Nov 9, 2016

View reviewed changes

sandersn added 3 commits November 9, 2016 13:39

Treat | undefined like optionality in spread type

fcf32c4

Add strictNullChecks test for object spread

9b1f43b

Merge pull request #12028 from Microsoft/object-rest

25462c9

Object rest

sandersn merged commit be5e5fb into master Nov 10, 2016

basarat mentioned this pull request Nov 14, 2016

Object spread basarat/typescript-book#189

Open

niieani mentioned this pull request Dec 23, 2016

type spread operator niieani/typescript-vs-flowtype#2

Closed

sandersn mentioned this pull request Jan 4, 2017

Spread type #13288

Closed

mhegazy deleted the object-spread branch November 2, 2017 21:03

microsoft locked and limited conversation to collaborators Jun 19, 2018

Object spread #11150

Object spread #11150

Conversation

sandersn commented Sep 26, 2016 • edited Loading

Important Update

Updates to proposed semantics: type variable assignability

Important Implementation Details

Updated proposal

Proposal syntax

Type Relationships

Assignment compatibility

Type variables

Type inference

Properties and index signatures

Call and Construct signatures

Precedence

Examples

Shallow Clone (excluding prototype)

Merging Two Objects

Overriding Properties

Default Properties

Multiple Merges

Getters on the Object Initializer

Getters in the Spread Object

Setters Are Not Executed When They're Redefined

Null/Undefined Are Ignored

Updating Deep Immutable Object

sandersn commented Sep 26, 2016

DanielRosenwasser commented Sep 28, 2016

sandersn commented Sep 28, 2016

DanielRosenwasser commented Sep 28, 2016

DanielRosenwasser left a 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

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

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

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

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

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

sandersn left a 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

sandersn commented Sep 26, 2016 •

edited

Loading