Destructuring

[ahejlsberg]

This pull request adds support for ECMAScript 6 destructuring declarations and assignments with down-level ES3 and ES5 code generation. For example:

var [x, y] = [10, 20];
[x, y] = [y, x];

The above example generates:

var _a = [10, 20], x = _a[0], y = _a[1];
_b = [y, x], x = _b[0], y = _b[1];

Another example:

interface NameAndLocation {
    name: string;
    location: [number, number];
}

function getNameAndLocation(): NameAndLocation {
    return { name: "top-left", location: [10, 20] };
}

function displayNameAndLocation({name, location: [x, y] = [0, 0]}: NameAndLocation) {
    console.log("name=" + name + " x=" + x + " y=" + y);
}

var {name, location: [x, y]} = getNameAndLocation();
displayNameAndLocation(getNameAndLocation());

The above example generates:

function getNameAndLocation() {
    return { name: "top-left", location: [10, 20] };
}
function displayNameAndLocation(_a) {
    var name = _a.name, _b = _a.location, _c = _b === void 0 ? [0, 0] : _b, x = _c[0], y = _c[1];
    console.log("name=" + name + " x=" + x + " y=" + y);
}
var _a = getNameAndLocation(), name = _a.name, _b = _a.location, x = _b[0], y = _b[1];
displayNameAndLocation(getNameAndLocation());

Work still remaining:

• Support for rest elements in array destructuring.
• Pure ES6 code generation with no rewriting (under -target ES6 switch).
• Updated spec.

[CyrusNajmabadi]

this is repeated below in the emitter. Extract out a helper 'isDestructuringAssignment' function.

[CyrusNajmabadi]

One thing that's unclear to me is how this works with the 'helicoptering' type operations we use for LS operations.

[CyrusNajmabadi]

You may want to make a new branch for this, with your code copied into it. Right now it's difficult to make out the changes post master-merge (esp in Github). Even looking at the change in a diff tool that can handle the change is tough as your changes are now mixed into everyone else's who checked in in the last month.

[ahejlsberg]

@CyrusNajmabadi Not sure what you mean by the 'helicoptering' question, but certainly the code is written such that you can helicopter into something like var [[[a]]] = [[[3]]]; and ask for the type of a and we'll do the appropriate 'reaching up and over' to infer type number.

Regarding a new branch, not sure that would help any. To get an all up view of how this branch is different from the current master (without everyone's intervening edits) just use the "Files changed" tab at the top of this page (instead of the link to the commit for the merge with master).

[CyrusNajmabadi]

Irony, i know: But this seems much more verbose than before.

however, that's not my major issue with this change. My primary concern is that by writing the code in this manner, it puts the onus on the maintainer to be sure that the saved state is restored properly. The prior form ensured that the state would always get saved/restored properly, and no changes could accidently affect that.

If you are concerned that you need to call parseIdentifierOrPattern with a parameter, and you don't want a lambda allocation, then this is a suitable way to write things:

node.name = inGeneratorParameterContext()
               ? doInYieldContext(parseParameterIdentifierOrPattern)
               : parseParameterIdentifierOrPattern();
...
function parseParameterIdentifierOrPattern() {
    return parseIdentifierOrPattern(SyntaxKind.Parameter);
}

[CyrusNajmabadi]

@ahejlsberg That was indeed what i was referring to when i mentioned 'helicoptering'. Does this support fall out naturally from teh existing code we have that walks upwards/outwards? Or was new code necessary to support the destructuring case? If the latter, could you point out where i should look to find it?

Thanks!

[ahejlsberg]

@CyrusNajmabadi The 'helicoptering' ability is in a sense a core requirement because we need the ability to obtain the type of any variable (including one deeply buried in a destructuring declaration) at any time (including both regular compilation and language service use). So, you could say it naturally falls out of the code, but there wasn't really a choice to do it any other way.

The interesting functions to look at are getTypeForVariableDeclaration and getTypeForBindingElement. They recursively call each other to walk up the chain of parent binding patterns to finally arrive at the top declaration. The root type obtained for that declaration is then broken down as the recursion returns to the leaf binding element.

Further nuance is added by the way in which a binding pattern can imply a type when no annotation or initializer is available from which to infer, and the effects this has on contextual typing. The newly added comments on getWidenedTypeForVariableDeclaration explain how this works.

[CyrusNajmabadi]

@ahejlsberg Awesome. Thanks for the explanation. It's definitely helpful to understand how all that 'helicoptering in/out' works. BTW, do you have a better term to describe that process?

[mhegazy]

👍

[JsonFreeman]

👍

[JsonFreeman]

Shouldn't the type be any if the parent type was any?

[ahejlsberg]

It is if there is not an initializer. If you're suggesting it should be any regardless of the initializer, then no. Consider:

var a: any;
var [x, y = 1] = a;

Here, a provides no clue as to the intended type of x and y, so we infer from the type of the initializer. This contrasts with:

var a: any;
var [x, y = 1] = [a, a];

Here, the type of a is the intended type for y, and the initializer is required to be assignment compatible with that type.

[JsonFreeman]

Do we do that for contextual typing? An analogous example (courtesy of @CyrusNajmabadi):

var v: (a: any) => void = (a = 1) { a.blah };

Should a in the body be of type any or number? Applying the reasoning you stated from destructuring, it seems like in this example it should be number, not any.

[ahejlsberg]

For a parameter the order of precedence is this:

• Explicit type annotation.
• Contextual parameter type.
• Initializer type.

For a binding element it is this:

• Deconstructed type (i.e. the type of the corresponding property or array element in the deconstructed value).
• Type of local default value (initializer) if type of deconstructed value is unknown or any.

So, you can't really apply the reasoning of one to the other. They're different kinds of constructs.

[JsonFreeman]

I understand that the way you described is how things are working, but it doesn't seem self explanatory why that is the case. Why are they different constructs?

[ahejlsberg]

I assume you agree with the already existing rules for parameters, so I won't try to elaborate on those.

For a destructuring element, the high order bit is the type of the value being deconstructed. Indeed, the initializer isn't even evaluated when a deconstructed value is available. So, this establishes the intuition that the binding element type should primarily come from the corresponding property or element in the deconstructed type. Then, in cases where the type of the deconstructed value isn't known or is any, it makes sense to take a clue from the initializer. That's the next best source of information.

[JsonFreeman]

That makes a lot of sense, but why is that not the case for parameters? I don't necessarily agree with the rules for parameters. I buy your argument about the destructuring and would like to apply it to parameters