Feature Request: Support intersections of object types

[SLaks]

TypeScript code: (this is a minimal example; I have a complex usecase involving builders in which I don't think there are alternatives)

export const x: {a: number}&{b: string} = {
  a: 42,
  b: 'hi!'
};

Actual Closure Code:

exports = {};
/** @type {?} */
exports.x = {
    a: 42,
    b: 'hi!'
};

Expected Closure Code: (what you get if you replace }&{ with ,)

exports = {};
/** @type {{a: number, b: string} */
exports.x = {
    a: 42,
    b: 'hi!'
};

[SLaks]

This is a special case of this TODO:

tsickle/src/type_translator.ts

Line 457 in 74aff76

// TODO(ts2.1): handle these special types.

[evmar]

Just making sure I follow, what do you suggest we do in cases like

type X = HTMLAnchorElement & {foo: string}

?

[SLaks]

I had assumed to ignore that & keep ?, but the fix I'm in the middle of writing ends up expanding out the full members of HTMLAnchorElement.

[draffensperger]

We recently ran into this with some code that used an intersection type for this (monkey patching a library function), which triggered the Closure unknown this conformance check for our codebase. See gist for details.

[mprobst]

@SLaks did you ever get around to working on this? I think #887 stalled?

[SLaks]

No; I no longer have time for this at the moment.

[mprobst]

Same here as on issue #1067 I think. We fundamentally cannot support this properly without support in Closure Compiler. Intersection types aren't just syntactical sugar for the expansion of their fields, even in a language based on structural types.

For an example, consider a recursive intersection type:

interface RecursiveIntersection {
  field: string&RecursiveIntersection;
}

There are similar problems with generic type parameters and so on.

I suspect it'll be very brittle to try and scope it down to a whitelist of supported cases, so I think accepting the loss of precision here is best we can do.

We could consider being more aggressive in the case of externs, where not emitting a type may actually break program optimization (basically @engelsdamien's case in issue #1067). We could error out in that case so that there's at least no silent failure.

OTOH, we'd need to carefully assess the impact of that. I suspect this might break a lot of existing .d.ts files.