@nicolo-ribaudo

I think that private methods should be transpiled exactly like private methods, because I could overwrite them. e.g.

class A {
  #x() { return 2 }
}

// ...

let _xMethod = function () { return 2 };

class A {
  constructor() {
    _x.set(this, {
      writable: true,
      value: _xMethod
    });
  }

}

var _x = new WeakMap();

This is because methods could be overwritten exactly as if they were fields, e.g.

class A {
  #x() { return 2 }

  setX() { this.#x = "foo"; }
}

@nicolo-ribaudo re: #1 (comment), private methods are not writable. Your second code snippet should result in a TypeError.

Oh right. I still think that we should use weakmaps with descriptors, since decorators (I will implement support for decorated private elements after that this PR is merged) can make private methods writable, or change them to be fields at runtime. Having a single way of accessing private things makes it a lot easier.

WeakMap versus WeakSet was a discussion we had 1-2 months ago with the team that is implementing private methods in TypeScript as well as the group that is behind the class fields proposal that's making it way through TC39 (e.g., @littledan). It also came up in my original PR for private methods back in September, which led to me rewriting the implementation (the original version of which actually did use WeakMaps) in that same PR about a month ago.

The main factor behind rewriting the WeakMap implementation to use WeakSet instead was that this is closer to the spec - private method descriptors have configurable: false and writable: false.

IIRC the performance cost of using WeakMap over WeakSet was an additional motivation behind rewriting the original implementation to end up with the current WeakSet output.

Given the above, is it possible to continue with the WeakSet implementation in conjunction with decorators? I'm not familiar enough with the decorator transform to know what level of complexity this introduces.

I think we could use WeakSet for private methods by themselves, and move to WeakMap if needed when decorators are in use. It is very unfortunate to have per-instance, per-method space overhead! The WeakSet representation has the potential to eliminate this by using the same set for a group of methods.

Ok we can go ahead with weak sets. If we see that having to have a different path for decorators makes things too complex we can always revisit the decision later.