Spreading private property is wrong

TypeScript Version: 3.1.0-dev.20180914

Code

class C {
    constructor(readonly x: number, private readonly y: number) {}
}
const a = { ...(new C(0, 1)) };
const b = { x: "", y: "", ...a };
b.x.toUpperCase(); // Error (good)
b.y.toUpperCase(); // No error (bad)

Expected behavior:

Error at the spread since that accesses a private property.
At least there should be an error at b.y since that accesses the same private property, and is a number at runtime.

Actual behavior:

No error except at b.x.toUpperCase() which is correctly an error.

[cancerberoSgx]

I have a similar issue - or concern with private class fields.

class C1 {
  private _a: number = 1
}
const c = new C1()
console.log(c) // C1 { _a: 1 }
Object.assign(c, {_a: 2})
console.log(c) // C1 { _a: 2 }

I wonder if TypeScript private members only apply to the types or also to the value/behavior of objects ? And even if only apply to types, I'm seeing issues when the compiler errors when assigning to types that should be assignable because of private members, when using spread operator, similar to your example

I'm trying esNext class private fields and the behavior is different. The private fields are never exposed, with or without spread operator:

https://babeljs.io/repl#?babili=false&browsers=&build=&builtIns=false&spec=false&loose=false&code_lz=MYGwhgzhAEDC0G8BQ1oGID6ZoF5oAYBuJAXyWAHsA7CAF2mF0QDpXoqBTAdzgAoBKMpRoUQHZiAoBzXsH5A&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=es2015%2Creact%2Cstage-2&prettier=false&targets=&version=7.4.4&externalPlugins=

In the case of TypeScript classes I need to manually patch the properties in order to not being exposed:

class C {
  constructor() {
    Object.defineProperty(this, "_a", {
      enumerable: false,
      writable: true
    })
  }
  private _a: number = 1
}
console.log(new C())

I wonder if this is the expected behavior or if there's any discussion similar to this ? If not, do you think is worthwhile to create an issue to discuss this and if it's viable to generate similar code automatically? Thanks!!!

[RyanCavanaugh]

Closing as Won't Fix - spreading a class is a weird thing to do in the first place, and it's not clear what the better semantics would even be.