Original rattrayalex private keyword proposal.md

Use a keyword (not necessarily private) as a "private this", such that private. is identical to the currently proposed #, but is used similarly to this.

class Point {
  
    private.x;
    private.y;

    constructor(x = 0, y = 0) {
        private.x = +x;
        private.y = +y;
    }

    get x() { return private.x }
    set x(value) { private.x = +value }

    get y() { return private.y }
    set y(value) { private.y = +value }

    equals(p) { return private.x === p.private.x && y === p.private.y }

    toString() { return `Point<${ private.x },${ private.y }>` }

}

Other possibilities for the keyword include:

• priv. (same length as "this", but perhaps too short / likely to exist in the wild).
• privates. (clear that it's like an object of slots, but possibly offensive).
• __priv__. (familiar to Pythonistas and reminiscent of __proto__, but I don't think that's a good thing).
• __this__. (I don't like it, but others might).
• privatethis. (arguably the most instructive, but long and ugly).
• protected (I don't think this would make sense, but may work if there is specific objection to private).

Advantages:

• private is already reserved, and would have no other reasonable use.
• # is the only "free sigil" left on a US keyboard for JavaScript (that I know of) and might be better saved for a feature* which would be used in both application and library code, rather than only library code.
• It is immediately clear what private. is for; # is not likely to be immediately clear.
• It would be friendlier to existing language tooling and implementations (eg; syntax highlighters, static analysis tools, and parsers would require minimal/no modification).
• It is more obvious that private.x and this.x are completely separate, and can peacefully coexist as unrelated fields.
• It resolves the surprising difference between this.#x and this['#x'].

Downsides:

• private.foo would likely be surprising to a Java or C# engineer, where private is used differently. (I would argue this is similar to the existing self/this differences).
• private is already implemented in TypeScript, and this would clash. (I would argue TypeScript would likely be able to adapt).
• private['foo'] would either need to be supported (which I'm not sure is possible/desirable) or explicitly disallowed, which would be surprising. (I would argue that only spec-reading library authors are likely to use this feature, and immediately understand why private[ is not allowed).

---

Note that the following initialization/declaration syntax is also a possibility:

class Point {
  private x = 0;
  private y;
  // ...
}

...though that may result in confusion when private.x is accessed.