Combining destructuring with parameter properties

Today, we can take advantage of parameter properties to reduce the boilerplate, e.g:

class Person {
  constructor(public firstName: string, public lastName: number, public age: number) {

  }
}

Since 1.5, we can also use destructuring, e.g:

class Person {
  firstName: string;
  lastName: string;
  age: number;

  constructor({ firstName, lastName, age } : { firstName: string, lastName: string, age: number }) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.age = age;
  }
}

I’ve tried in many ways to combine both features, but had no success. So:

1. Is it possible to combine them nowadays, and if yes, how?
2. If not, could it be an improvement to a future TypeScript version? E.g:

class Person {
  constructor(public { firstName, lastName, age } : { firstName: string, lastName: string, age: number }) {

  }
}

// the code above would possibly transpile to:
var Person = (function () {
    function Person(_a) {
        var firstName = _a.firstName, lastName = _a.lastName, age = _a.age;
        this.firstName = firstName;
        this.lastName = lastName;
        this.age = age;
    }
    return Person;
})();

[GusBuonv]

As I saw no push back against it and a good showing of support for it, I’d like to resurface and bump @markm77’s suggestion on this. To repeat the proposed syntax:

interface Data {
  foo: string
  bar: string
}

class A {
  // new syntax simultaneously declares properties with access and mutability specifiers and initializes them from argument properties
  constructor({
    readonly public foo,
    readonly public bar,
  }: Data) {}
}

To me this suggestion has the following advantages:

• It solves the original problem.
• It is an easy-to-understand extension of an existing feature (JavaScript’s argument unpacking).
• It cuts down on boilerplate.
• It reduces the potential for errors in constructors (e.g. accidentally assigning data.foo to this.bar, unsafe & unnecessary reliance on Object.assign, etc).
• It facilitates a basic design pattern: classes wrapping interfaces with functionality.
• It does not rely on exotic or unfamiliar extensions to the language.

I would like to see this option get more discussion, so here are some questions that might get this moving. Is there anything that makes this impossible or overly burdensome to implement from a technical standpoint? Is there anything about the syntax that makes it unclear or prone to causing errors? Does this syntax fall short of facilitating the feature at the root of this thread?

[RyanCavanaugh]

Accepting PRs to implement constructor(public {name1, name2}) forms (i.e. no public / private etc inside the {}s).