`this['#myVar']` will access the public field named `#myVar`, so it's the same as the `example` method.

>If they are different it's very inconsistent and IMHO a lot worse.

It is called out in the link I posted above as a "downside", and I agree that it sucks, but there aren't any other good options for this without breaking compatibility with current code.

>I worry about trying to understand other people's code

Luckily there is one big benefit to this that makes the impact of the weirdness surrounding the naming much less awful. Because of the "hard encapsulation" that the private fields have, they are literally and explicitly un-viewable, un-accessible, and un-usable outside of the class body.

So the amount of complex meta-programming and many of the reasons you'd want dynamic property access in the first place (iterating, monkey-patching, using arbitrary strings as keys, computed keys, etc...) aren't applicable, and if you really want those features but also with privacy, you can nest a plain object as a private field and work with it that way just the same.

So it may have some gotchas, but because the proposal is intentionally restricted as much as possible, and it explicitly disallows a lot of the metaprogramming that can be common and it only allows a very simple lookup syntax, the weirdness is very well contained, and at worst will be confined to between the opening and closing brace of a `class` statement.

That's the thing, current code is not using the `private` keyword since it's not valid, so it would not break anything and would be totally retro-compatible. `example.myVar` will still work whether or not it's possible to create a private prop called `myVar`, because it's just not created now since you cannot do `private myVar` now. Now, I do agree that it might be confusing in the future as well and might be not future-compatible, but it is for sure retro-compatible...

But then what happens if you have `private myVar` and you need to access the public `myVar` from within the class?

That's not an extreme hypothetical, it was a real example from someone trying to use this feature. They had tried to emulate private fields with an underscore before, people started using the private variables, and now they want to refactor while keeping the current "private-turned-public" variable working the same.

I'm sure you can come up with answers for most of those things, but will they really be easier to understand than the current proposal? I'd hate if I have to look around in the class any time `this.anything` happens to see if it's private, public, shadowed, a getter/setter, etc...

`this.#myVar` is explicit, it's obvious, and even if it's ugly as a sin, you know it's not doing something "normal" right away.

If `myVar` is defined as private then it cannot be re-defined as public... It seems simple. It's the same as normal variables: what happens if you define myVar as `const` and then you want to redefine it as `var`? Well, you cannot, you'd have to work around it instead.

But then the private variables can impact code outside of the class, and and they are no longer truly private.

Imagine you are using a library and extending it adding a few properties for usage in your app, and one patch upgrade your app breaks because the `example.tag` stops working because the library decided to add `this.tag` as a private variable.

Imagine React decides to use this, and they add a private `this.internalState`, but all react components are extended from that. So now all react components can't use `this.internalState` and if the react team ever changes the name of the private variables, then it is a breaking change and can cause code to stop working.

You can say "well don't do that" all you want, but a good portion of the web uses techniques like that, and breaking code because you feel they are doing it wrong doesn't make a healthy ecosystem.

Ah I see, that makes a lot of sense, thanks for the clarification. I still think it'd have been a fair compromise anyway, but it's not ideal and not easy as I thought.