Destructuring function overloads with strictNullChecks produces invalid .d.ts

[rkirov]

TypeScript Version: Version 2.1.0-dev.20160801

Code

class A {
    f({x}: {x?: boolean} = {}) {};
}
class B extends A {
    f({x, y}: {x?: boolean, y?: boolean} = {}) {};
}

with strictNullChecks the code is accepted and the following .d.ts produced

declare class A {
    f({x}?: {
        x?: boolean;
    }): void;
}
declare class B extends A {
    f({x, y}?: {
        x?: boolean;
        y?: boolean;
    }): void;
}

Expected behavior:
Since the original code is accepted, the .d.ts file should also be accepted.

Actual behavior:
When passed to tsc with strictNullChecks the .d.ts in question produces the error

test.d.ts(7,8): error TS2459: Type '{ x?: boolean | undefined; y?: boolean | undefined; } | undefined' has no property 'x' and no string index signature.
test.d.ts(7,11): error TS2459: Type '{ x?: boolean | undefined; y?: boolean | undefined; } | undefined' has no property 'y' and no string index signature.

Confusingly, if you removed the inheritance the signature for B is accepted.

In general, I am surprised that TypeScript keeps any mention of destructuring in the .d.ts. In my mind that is part of the implementation of the function and has no relevance to the function signature. What would happen if TS plainly emits - f(a?: {x?: boolean;}): void;.

[ahejlsberg]

Definitely looks like a bug.

In general, I am surprised that TypeScript keeps any mention of destructuring in the .d.ts. In my mind that is part of the implementation of the function and has no relevance to the function signature. What would happen if TS plainly emits - f(a?: {x?: boolean;}): void;.

I actually agree, and that was our original intent. However, a key issue is that we have no good parameter name to substitute in place of a destructuring pattern. You'd end up with auto-generated names like _1 or p1 instead of the arguably more informative {x, y}.

[RyanCavanaugh]

@sheetalkamat can you take a look? Thanks!