scoped-private.md

Sketch: scoped private fields

So far, private fields are introduced as follows:

class MyClass {
  #privateField = 123;
}

I’d like to propose a small extension: scoped private fields.

Functional style (the proposal)

The following style is becoming popular in the JavaScript world. It benefits from scoped privacy:

private #data;

function createStringBuilder() {
  return {
    #data: '',
  };
}

function add(sb, str) {
  sb.#data += str;
}

function toString(sb) {
  return sb.#data;
}

New in this code:

• The keyword private in the first line.
• The ability to use private fields in object literals.

OOP style

As a slight downside, you now always need to use the keyword private:

class StringBuilder {
  private #data = ''; // keyword is required
  add(str) {
    this.#data += str;
  }
  toString() {
    return this.#data;
  }
}

On the upside, this gives you the freedom to widen the scope of privacy:

private #data;

class StringBuilder {
  #data = ''; // no keyword!
  add(str) {
    this.#data += str;
  }
}
function toString(stringBuilder) {
  return stringBuilder.#data;
}

Alternative syntax

Alternative syntax has been proposed:

• Keyword private not needed for “normal” private fields.
• Two keywords if you want to widen the scope of privacy: private and outer.

Example:

private #data;

class StringBuilder {
  outer #data = ''; // keyword is now required
  add(str) {
    this.#data += str;
  }
}
function toString(stringBuilder) {
  return stringBuilder.#data;
}

FP example:

private #data;

function createStringBuilder() {
  return {
    outer #data: '', // keyword is now required
  };
}

function add(sb, str) {
  sb.#data += str;
}

function toString(sb) {
  return sb.#data;
}

# is blatantly awful, non-intuitive and will only fuel the JavaScript is a flawed language adage (which I have to agree to if this # symbol is introduced). private should be the way to declare private fields. The fact we're having a year-long discussion about this thing is what sometimes makes me question the reliability of the process (and people) upgrading JavaScript. Please, use private.

private is not an option for JavaScript: https://2ality.com/2019/07/private-class-fields.html#why-the-%23%3F-why-not-declare-private-fields-via-private%3F

Using # is just awful, it does not follow standard JavaScript declarative syntax. It feels more like a PHP-style declaration (using symbols for declaration, $ for example) than a standard JavaScript-style declaration (using keywords for declaration, let for example).

@rauschma's comment and the FAQ on the proposal make it clear as day to be honest - it makes sense for the language. Yes, it looks ugly at first and not like standard JavaScript style declaration (which uses keywords for everything else), but I think we'll get used to it. On the other hand, I was wondering if during compile time, private field can be mapped over to #field ? I guess that means during access you'll have to remember to use the #, but during declaration it would look different. Not sure if that would be better or not actually, but it seems like a good middle ground?

~ thankful for everything OSS contributors do, and the TC39 committee as well!

wouldn't _ be viable if at the top of the file something tells the compiler that it is reserved so that it doesn't break current functionality, something that is like "use strict"; but for _? # is a horrible solution.

No existing identifier is viable, because var _ = something at the bottom of the file hoists it ti the top, and there could be silent conflicts.

But the whole point of the comment/code at the top was to tell the compiler to act in a specific way? Like bash's #!/usr/bin/env bash, am I missing something?

That would be a new mode (like strict mode), and the committee is pretty firmly against ever adding another one. In addition, the refactoring hazard would be large, as code that works fine in one file would suddenly work differently in another.