Normative: Remove own restriction on PrivateName

[littledan]

Given the Stage 3 resolution on the static class features issue,
static private is now permitted. This patch removes the corresponding
restriction for decorators, which was probably left in as a relic of
that issue.

[nicolo-ribaudo]

Can the placement be "prototype"?

[littledan]

@nicolo-ribaudo I believe we should permit this, for the same reason as in #57 .

[nicolo-ribaudo]

Before #57, "prototype" was already disallowed (also, it is indicated as disallowed in #16 (comment)). I understand why static private fields should be allowed (static #x is valid), but I don't get why also prototype private fields.
Also, having them on the prototype gives the false expectation that they should also be accessible from the instance, while they aren't (unless I'm wrong):

class Foo {
  @moveToPrototype
  #foo = {};

  @moveToPrototype
  bar = {};

  getFoo() { return this.#foo; }
  getBar() { return this.bar; }
}

new Foo().getBar() === new Foo().getBar(); // Works, because getBar gets this.__proto__.bar;
Foo.prototype.getFoo() === Foo.prototype.getFoo(); // Works, because it gets Foo.prototype.#foo;
new Foo().getFoo() === new Foo().getFoo(); // Throws, because it doesn't get this.__proto__.#foo but this.#foo

function moveToPrototype(desc) {
  desc.placement = "prototype";
}

[littledan]

That's right, they wouldn't be accessible from the instance. Decorator authors would be expected to understand exactly how private works.

[littledan]

Any other opinions on whether we should accept prototype private? Given the concern raised here, I'm thinking to make a more minimal change, to just permit static private, which would be a pure bug fix given the Stage 3 private static proposal.

Edit: Pushed more minimal change.

[nicolo-ribaudo]

We can discuss the prototype placement in a new issue.