Inline type annotations for rebinded destructuring parameters

[d180cf]

I've seen a discussion around this in Flow, but couldn't find one here. The discussion was around this (desired, but not actual) syntax:

function fn({ a: number, b: string as b2 }) {
  return a + b2;
}

This is what a ts user expects to write and this is what I often mistakenly write despite I'm quite familiar with ts. The problem with this syntax is known: it conflicts with the ES6 spec which says that { a: number } means let number = arguments[0].a

However, in the syntax for importing stuff from modules, ES6 spec uses a different syntax:

import { each as forEach } from "jQuery";

Which I personally find easier to understand, but what's more important is that it leaves a room for a ts type annotation:

import { each: Function as forEach } from "jQuery";

What I'm asking for is probably an unheard of thing: can ts deviate from the ES6 spec in this particular place and treat { b: string as b2 } syntax as "parameter b of type string rebinded to variable b2"?

[DanielRosenwasser]

I don't think we could use that specific ordering given that we've added a new as type assertion operator (written in the form value as Type).

[d180cf]

The as operator seems like another way of casting the type and it can't appear in { b: string as b2 } syntax.

[DanielRosenwasser]

Sorry, what I really meant by that is that it would be confusing to do so. Users would have to remember that

1. imports use as and object binding patterns use : (already slightly annoying to remember)
2. the as operator is ordered as expression as Type (not much of a problem),
3. to give an inline type in an object binding pattern, the syntax is : Type as name (not consistent with the other two).

[d180cf]

In #1 I'm suggesting to use "as" in object binding patterns as well (which contradicts to ES6 and may have problems with nested destructuring): const {b as b2} = fn();

[RyanCavanaugh]

We need to just leave this area alone -- there's too much room for conflict with ES7+ activity, and adding any more syntax or variations is more likely to increase confusion than decrease it (as we've seen with the ES6 module import syntax).