Destructuring with type annotations

[osi-oswald]

Using destructuring in functions signatures is a relief, but when combining it with type declarations there is a lot of duplication necessary:

function foo(
  {paramA, paramB, paramC, paramD = null}
  :{paramA: number, paramB: string, paramC: boolean, paramD?: Object}
) {}

function bar(
  [paramA, paramB, paramC, paramD]
  :[number, string, boolean, Object]
) {}

Would it make sense to introduce the following syntax to reduce duplication of code?

function foo(
  {paramA as number, paramB as string, paramC as boolean, paramD? as Object}
) {}

function bar(
  [paramA as number, paramB as string, paramC as boolean, paramD as Object]
) {}

Originally I wanted to suggest to use the colon ":" instead of the "as", but since the colon is used for renaming destructured parametes, the "as" is the only option I guess.

With this syntax change the following would be possible too I guess:

let {paramA as number, paramB as string, paramC as boolean, paramD as Object} = anyObject;
let {paramA: a as number, paramB: b as string, paramC: c as boolean, paramD: d as Object} = anyObject;
let [paramA as number, paramB as string, paramC as boolean, paramD as Object] = anyArray;

[mhegazy]

We have talked about this as a possibility during the design of the destructuring support. a few thoughts,

• as should have been using for the rename operator instead of :, that maps well to the import case where as is used to rename an import or export name binding, e.g. import {a as b} from "m" or import * as ns from "m".
• there is value in consistency that types always come after a :. adding another operator would increase complexity.
• there is a possibility of the committee (TC39) using as in the future, again to align with imports as an alternative for renaming. at this point we would be in a bind. we have the : domain almost officially reserved for types.
• the compiler will infer the types from initialization, and we have done multiple iterations of improvements on the inference logic, to make sure you do not need to type out a type unless you have to, see https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#improved-checking-for-destructuring-object-literal for more details.
• ultimately, every new syntax added is added complexity, for the user to learn and recognize, and for the compiler code base to maintain, so usually we try to limit complexity unless the value warrants it. and for destructuring, the syntax is already complex to start with, and we did not want to add yet another layer on top.

[DanielRosenwasser]

I think we're going to need to decline this one. Adding any more syntax here would put us in a tough spot, and on the whole, I think this would confuse users quite a bit.

[cletusw]

I have to second this request. Without some solution to this issue, I'm strongly inclined to avoid parameter destructuring in TypeScript even if it means going back to the days of myMethod(param1, null, null, 2, null, null, true). It's just too much overhead to maintain two separate lists of parameters, one for types and another for default values.

[cletusw]

Note that this issue combined with #5326 make destructuring extremely verbose for class constructors, negating a ton of improvements I've made to my ES6 code that I'd lose moving to TypeScript.

[aluanhaddad]

@cletusw --noImplicitAny is fully optional. You can use parameter destructuring and all of the properties will be of type any, just like they would had your written your code for Babel. So you would lose absolutely nothing.

[cletusw]

This is true, although I'm relying heavily on noImplicitAny to help me find all the places that need types, so I would be loathe to turn that off.

[aluanhaddad]

@MichaelBuen I fully agree. The rename syntax is not only awkward and incompatible it is also inconsistent with imports which obviously are a natural analogy even though they have different semantics.

It is also not that the committee didn't envision TypeScript or Flow, as typed ECMAScript dialects existed before the standard was finalized.

As best I can tell, the reason for using the : comes from a desire for symmetry between composing and decomposing object literals.

[MichaelBuen]

How about this?

function foo({surname string, birthDate Date})

If a code..

function foo(dto: {surname: string, birthDate: Date})

.. need to be improved to use destructured object, instead of this proposed syntax..

function foo({(surname: string), (birthDate: Date)})

.. which entails going to each variable and surrounding each of them with parenthesis, it's tiresome and makes the code looks so busy. It would be easier to just remove the colon:

function foo({surname string, birthDate Date})

And when it's need to be renamed, just use the already established syntax for renaming:

function foo({surname string: apellido, birthDate Date: fecha})

Maybe ES6 committee decided that renaming destructured object would be the norm, so they choose a terse syntax to rename something. But why ES6 didn't dream of JavaScript of having types someday, or having TypeScript being part of the browser? Had they thought of it, they would not choose colon for renaming variable, they would use as for renaming, which is symmetrical with import statement. Another alternative would be is not to use an operator at all, same with SQL:

SELECT * FROM Person as p

Not using as would be just as fine:

SELECT * FROM Person p

So renaming surname to apellido would be:

function foo({surname apellido, birthDate fecha})

const {surname apellido, birthDate fecha} = person;

And then when in the not-so-distant future that JavaScript would have types. Boom! they could just use the established syntax for declaring types:

function foo({surname apellido: string, birthDate fecha: Date})

const {surname apellido: string, birthDate fecha: Date} = person;

function foo({surname: string, birthDate: Date})

const {surname: string, birthDate: Date} = person;

Too late.

Will just wait for WebAssembly to take off, and wait for a language that has a nicer syntax :) It might also be our chance for a language to have a decimal type.

I highly suggest this syntax..

function foo({surname string, birthDate Date})

..it's not really weird to remove an operator for declaring types, e.g.

CREATE TABLE Person (
    PersonID  int,
    LastName  varchar(255),
    FirstName varchar(255),
    Address   varchar(255),
    City      varchar(255) 
);

Another advantage of the above over this one..

function foo({surname as string, birthDate as Date})

..is if ECMAScript committee decided to make the renaming use the as keyword so there's symmetry with import's as, this won't cause breaking change:

function foo({surname string as apellido, birthDate Date as fecha})

function foo({surname as apellido, birthDate as fecha})

const {surname string as apellido, birthDate Date as fecha} = person;

const {surname as apellido, birthDate as fecha} = person;

Whereas this one would cause breaking change when as would be introduced for renaming destructured object. Both surname and birthDate would have any type when as would be used for renaming in the future:

function foo({surname as string, birthDate as Date})

const {surname as string, birthDate as Date} = person;

[MichaelBuen]

Indeed, destructuring using colon operator gives symmetry for composing and decomposing between object literals.

However, when I first use destructuring it felt reversed:

const person = {lastname: 'Eich', birthDate: Date()};

const {lastname: apellido, birthDate} = person;

console.log(apellido);

I was expecting the new name would be on left, and is symmetrical with how the object is composed:

const {apellido: lastname, birthDate} = person;

Perhaps they decided that it would be easier for users to scan/read all the object's original property names when they are on left. And they would like the users to mentally read the colon as as.

[aluanhaddad]

Personally I also think as would have been better. I had the same intuition, thinking the names were backward. Then again maybe it's because I was used to looking at types in that position. Regardless, I see no reason why the syntax is different than that used for aliasing imports...