Repository: TypeScript
Issue: Allow a type annotation for indicating the type of a destructured rest assignment
Labels: Suggestion,Awaiting More Feedback

# Suggestion

I offer allow to assign type to rest in destructuring assignment.

<!--
  Please fill in each section completely. Thank you!
-->


## 🔍 Search Terms

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->

destructuring assignment, desctructuring, rest

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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, new syntax sugar for JS, etc.)
* [X] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

```js
const { e, ...rest }: { e: number, ...rest: ICalculatedNumbers } = test;
```
For better understanding please check **Use Cases**

## 📃 Motivating Example

I wanted to assign new calculated value to destructured assigment to field that moved out to new variable by destructuring, but I can't do it because new type exists without field and I'm not able to assign new type to desctructuring assignment.

Provided example in **Use Cases**

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

## 💻 Use Cases

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

### Current behavior in TypeScript
```js
export interface INumbersE {
    c: number;
    d: number;
}

export interface INumbers {
    a?: number;
    b?: number;
    c?: number;
    d?: number;
    e?: INumbersE;
}

export interface ICalculatedNumbers {
    a?: number;
    b?: number;
    c?: number;
    d?: number;
    e?: number;
}

const calcTheNumber = (numbers: ICalculatedNumbers) => {
    // another logic goes there
    console.log(numbers);
}

const test: INumbers = {
    a: 1,
    b: 2,
    c: 3,
    d: 4,
    e: {
        c: 2,
        d: 3
    }
};


const { e, ...rest }: { e: number, ...rest: ICalculatedNumbers } = test; // Property 'rest' is missing in type 'INumbers' but required in type '{ e: number; rest: ICalculatedNumbers; }'

if (e && e.c + e.d === 5) { // Property 'd' does not exist on type 'number' || Property 'c' does not exist on type 'number'
    rest.e = 5; // Property 'e' does not exist on type '{ a: number; b: number; c: number; d: number; }'
}

calcTheNumber(rest); // Type '{ rest: ICalculatedNumbers; }' has no properties in common with type 'ICalculatedNumbers'.
```

### Running in pure JS right as expected behavior and getting expected object with **e: 5**
```js
const test = {
    a: 1,
    b: 2,
    c: 3,
    d: 4,
    e: {
        c: 2,
        d: 3
    }
};

const calcTheNumber = (numbers) => {
    console.log(numbers); // { a: 1, b: 2, c: 3, d: 4, e: 5 }
}

const { e, ...rest } = test;

if (e && e.c + e.d === 5) {
    rest.e = 5;
}

calcTheNumber(rest);
```

If cover errors with `//@ts-ignore`, it'll run as expected, but I'm not ok with that.