Destructuring Type Syntax Sugar

[mavericken]

Destructuring still leaves much to be desired when it forces a lot of unnecessary repetition.

The best idea I saw is actually in the original issue for tracking destructuring:
#240
I feel that idea has mostly been overlooked and now forever sits in a closed issue, and that it deserves a second look.

@fdecampredon commented on Oct 20, 2014

For syntax of type annotations I would prefer the first option :

var {x: myX: number, y: myY: number} = myPoint(); // with renaming
var {x:: number, y:: number} = myPoint(); // without renaming

than having over verbose syntax that force us to repeat the var names, especially for function arguments destructuring.

function myFunc({x::number, y::number }) {
}

Seems a lot easier to read for me than :

function myFunc({x, y}: {x: number; y: number}) {
}

I saw some related issues, but with not as good of syntax proposals. I include them for linking and reference:
#10079
#7576

[mhegazy]

Please see #7576 (comment).

TS is intended to be a super-set of JS; this entails following the ECMAScript spec, and also not introducing new syntax that may conflict with future ECMAScript direction. Moreover, the main issue here is that the use of colon to rename properties goes across how type annotations are specified in TS; so the main issue is discoverablity and intuition, and for that i do not think the :: is any more discoverable nor intuitive for users.

I personally do not like the destructuring syntax, and believe as should have been used here for renaming, but TC39 has decided, and I do not think i get to change it now.

[mavericken]

I don't think I buy discoverability as an argument. It has never really been my experience that I can expect to just start typing new syntax and it just does exactly what I wanted. The current syntax is a perfect example of this, as I recall spending at least 15 minutes trying to figure out why ({a:number})=>a didn't expect to see a.

I think :: is intuitive in the same way ;; in for(;;){/*ever*/} is intuitive. We simply didn't put something in between the two colons, so they just ran together. It also seems intuitive to me to just not rename something if the new name is omitted, similarly to how a for(;;) loop simply doesn't check to see if it should stop running.

Tacking :typeName on the end of something is the first thing anyone learns about TypeScript, so it seems perfectly intuitive to do the same thing here to apply a type.

[SimonMeskens]

You didn't address his main issue, being that :: is being actively considered for other features. Also, I personally like the current syntax better and think that for(;;) is VERY unintuitive and a good example to the contrary. I've actually refactored that exact syntax in the past, and put it in the style guide as something to avoid, because it was causing too much confusion.

The current syntax looks like you are annotating vanilla JS, which is exactly what you're doing. The syntax you propose looks confusing and unclear. Even if I figure out a rename is going on, is the first one the original name? The second one? Actually, looking at the example right now, I'm not even sure. I assume the first one, looking at the other example?

[aluanhaddad]

@mavericken :: has been proposed for an ECMAScript feature in the past, the function bind operator, the status of which is still unclear.

The current syntax is a perfect example of this, as I recall spending at least 15 minutes trying to figure out why ({a:number})=>a didn't expect to see a.

I had the exact same experience, and I reckon many others did as well. That in itself is a very good reason not to use ::.
Adding a second : is like trying to recapture the intuition you just lost by using a single : to rename in the first place, all it does is make things that much more confusing.
As you say the current syntax is awkward but as @mhegazy points out it is not going anywhere and is not something that TypeScript controls.

[mavericken]

I am adverse to just accepting that there is nothing we can do about it, though. The name:rename:type idea could work, and even if :: was used in EMCAScript later, it would likely not conflict inside destructuring syntax. So I would say yes, we can do something about it.

That being said, the idea has at least gotten the light I thought it deserved, even if not the support... Assuming no support arrives, I'll give an opportunity for any last words and then close.

[aluanhaddad]

@mavericken
I'd love to see a solution I just don't think that's the right one.
If anything I think using is would be better.

const { id: name is string } = o;

But that could probably clash as well.

[mightyiam]

Why isn't { foo: bar : string } possible?

[mightyiam]

Suggestion:

{ foo string }
{ foo: fooHere string }
{ foo string, bar number }
{ foo: food string, bar: bart number }
{
  thing Thing,
  thung Thung,
  thong: nsfw Thong,
  i number,
  name string,
  x: cX Coordinate,
  y: cY Coordinate
}