Suggestion: Support type assertion on destructuring syntax

[zheeeng]

Code

Maybe we need a convenient way to add assertions on variables which are destructured out.

    type StringOrNumber = string | number
    
    const obj = {
      foo: 42 as StringOrNumber
    }
    
    const { foo } = obj

Nowadays, the workarounds are:

    // A:
    const { foo } = obj as { foo: number }

    // B:
    const { foo: foo2 } = obj

    const foo = <number>foo2

The first is a burden to rewrite the obj's type when its type is nested and complicated. The second seems weird.

I'm assuming such a syntax like:

    const { <number>foo } = obj

can absolutely help us asserting the type no matter how big the obj's type is.

[rozzzly]

Not sure how I feel about this proposal... But I would suggest using the as keyword instead of the angle brackets for the type assertions.

It could look like:

const { age as number, name as string } = person;

Where the type of person is any.

[zheeeng]

@rozzzly Generally using as is better than mine, the problem is that import syntax has employed this keyword and has the exact same usage.

[kitsonk]

This is essentially a duplicate of #1912.

[zheeeng]

@kitsonk Didn't find a solution to relieve the pain point on casting type on value nested in object. May a simple workaround or a new sound syntax cloud be discussed.

[mhegazy]

Please see #13471 and #7576

[andrewrothman]

I understand (from this and the previous issues) that there is still room for discussion on the syntax of this operation, but I think it would be really great to have this feature, as something that a lot of developers have become accustom to.

Personally I feel the best approach would be:

const { name: string, age: number } = person;

But regardless of syntax, I'd love to see this feature in a TS release! You all have done such a great job at making our lives easier with a more structured and flexible programming language.

[kitsonk]

const { name: string, age: number } = person;

That conflicts with ES spec of assigning to new variable names when destructuring. Breaking that for everyone would result in lots of tears. Because there is no straight forward syntax is the main reasons why the current methods are likely here to stay.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.