Conditional spread results in weird union type, with duplicates

[DanielRosenwasser]

interface Animal {
 name: string;
 kind: string;
 age: number;
 location: string;
 owner: object;
}

function clonePet(pet: Animal, fullCopy?: boolean) {
 return {
 name: pet.name,
 kind: pet.kind,
 ...(fullCopy && pet),
 }
}

Expected: clonePet returns type { name: string, kind: string, age?: number, location?: string, owner?: object }

Actual: clonePet returns the following type:

{
 name: string;
 kind: string;
} | {
 name: string;
 kind: string;
} | {
 name: string;
 kind: string;
 age: number;
 location: string;
 owner: object;
}

[DanielRosenwasser]

Any clue if this is working as intended Anders Hejlsberg (@ahejlsberg) Wesley Wigham (@weswigham) Andrew Casey (@amcasey)?

[DanielRosenwasser]

Another example that Nathan Shively-Sanders (@sandersn) had come up with

interface Animal {
 name: string;
 owner?: string;
}
function billOwner(pet: Animal) {
 return {
 ...(pet.owner && pet),
 paid: false
 }
}

[ahejlsberg]

I'm a bit surprised the same type is in there twice, but otherwise it's an effect of us not performing union subtype reduction in object literal spreads.

[DanielRosenwasser]

Right - I actually thought that that was where the slowdown originally came from: creating every combination of types of spreads, followed by subtype reduction on extremely similar types. I guess it was just creating each possibility, which I think is still exponential.

[weswigham]

The multiple-of-the-same-object-type thing is something that's always been an unfortunate possibility in a spread. That example you have there gives the same output in older TS, too.

[AnyhowStep]

The second output seems more correct to me (ignoring the duplicate union element).

Because I doubt this is desired,

const clone = clonePet(pet, true)
clone.location = undefined //probably not desired?

I just read the 4.1 RC release notes. Didn't realize the optional props are now expected behaviour.

[DanielRosenwasser]

The duplicate is just "unfortunate" but it's a distraction. I think this behavior is inconsistent otherwise because the real thing I'm reporting is that we're not getting optional properties, and I can't coherently explain this behavior.

[weswigham]

The duplicate is directly the cause of the behavior (which also exists in older TS versions provided you use single-property additions). This is because our spread object-combining logic only permits combining exactly two types, so if you have three types (even if two are identical), we skip the whole simplification process (which is the only thing that produces optional properties) and do the big union-all-the-possibilities plan.