Repository: TypeScript
Issue: Easier destructuring with type annotations on binding patterns
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

type inference destructuring syntax conflict

## Suggestion

<!-- A summary of what you'd like to see added or changed -->


It's currently not possible to destructure a value in Typescript and provide types for each of the values due to the syntax clash with destructuring and renaming at the same time. You can see exactly this issue in the Typescript FAQs at: https://github.com/Microsoft/TypeScript/wiki/FAQ#why-cant-i-use-x-in-the-destructuring-function-f-x-number------

This is frustrating when programming in React where it's very common to see this pattern:

```typescript
const MyComponent = ({ a, b }) => {
    // ...
}
```

But in Typescript a and b are untyped (inferred to have type `any`) and type annotation must be added (either to aid in type safety or to avoid compiler errors, depending on the state of the user's strict flags). To add the correct type annotation it feels natural to write:

```typescript
const MyComponent = ({ a : string, b : number }) => {
    // ...
}
```

but that's not what the user thinks due to the aforementioned syntax clash. The only valid syntax in Typescript is actually this:

```typescript
const MyComponent = ({ a, b } : { a : string, b : number }) => {
    // ...
}
```

Which is very strange to write and difficult to read when the object has more than two parameters or the parameters have longer names. Also the value names have been duplicated -- once in the destructuring and once in the type annotation.

I suggest we allow some other symbol (my current thinking is a double colon) to make the syntax unambiguous in this specific scenario:

```typescript
const MyComponent = ({ a :: string, b :: number }) => {
	// ...
}
```

Although this is really the only place it would be used, for the sake of consistency, I think is should be allowed everywhere:

```typescript
const a :: string = "";
const b :: number = 1;
```


## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

It would allow for type-safe destructuring of values where the type cannot be inferred by the compiler (such as function parameters).

## Examples

<!-- Show how this would be used and what the behavior would be -->

A good example of the sort of React components I'm talking about (and one of the first Google results for React Functional Components) can be found at https://hackernoon.com/react-stateless-functional-components-nine-wins-you-might-have-overlooked-997b0d933dbc. We can use my proposed syntax in the functional component definition:

```typescript
import React from 'react'

const HelloWorld = ({name :: string}) => {
	const sayHi = (event) => {
		alert(`Hi ${name}`)
	}

	return (
		<div>
			<a href="#"
			   onclick={sayHi}>Say Hi</a>
		</div>
	)
}
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).