in does not preclude shorthand?

[bmeck]

I'm a bit confused by:

Specifically, this is because if #brand (in the previous example) is a shorthand for this.#brand, then (#brand) in obj would have to mean the same as this.#brand in obj, which means "is the value of this.#brand in obj?", not "does obj have the private field #brand?".

Why is #brand in obj problematic? this.#brand is the reference to the property value of #brand on this so it doesn't collide with the environment reference #brand to my knowledge.

[ljharb]

Because in k in this, k isn’t a string, it’s an expression - if #k is a shorthand for the value of this.#k, then one might expect #k in obj` to check if the value of the field on the receiver is in the object - but this proposal would have already locked that down as part of the grammar.

[bmeck]

#k has multiple proposals potentially using it. I was thinking about https://github.com/tc39/proposal-private-declarations as having the same usage as an environment variable as key rather than this. shortcut. Thanks for clarifying, but it seems to only preclude 1 type of forwards usage, maybe this could be called out as constraining rather than precluding usage of #foo as an expression.

[ljharb]

I'll clarify - it's not that it constrains its use as an expression, but i think it specifically prevents its use as shorthand. It intentionally does not conflict with the private declarations proposal.

[hax]

@ljharb

I think this thread is just a symptom of the big issue what I am talking about, but of coz you can disagree.

those expectations may support future proposals around making #x a first-class thing.

This is what I'm asking, if we want make #x first-class in the future, how to explain it? It's very likely we will make key in obj become much complex and hard to explain.

[ljharb]

If #x becomes, say, a first-class symbol, then #x in obj would mean the same thing (is that private symbol in the object) as 'x' in obj (is the string x in the object) or x in obj (is the string or symbol or private symbol contained in x in the obj). To my mind it fits perfectly with that potential future.

[bmeck]

I'd agree that #x in obj is not problematic and even go so far as to state that #x as a private symbol must not have issues since a first class symbol wouldn't use # if it is a first class value (in this case a symbol it was pointed out that syntax would be needed for non-reified forms).

[Alexsey]

1. I think that choice between if #x should be a value or symbol is obvious: it must be a value. Because in real code we are manipulating values in 95%+ of cases and manipulations with keys (no matter string or symbol) is much rarer. And something that is getting used more often should be more ergonomic while something that is getting used less often should be less ergonomic

2. Going forward with #x in obj will lock potential future shorthand proposal to be a symbol. But it's a very bad choice for symbol comparing to string keys: we can manipulate strings, compare them and concatenate. #x doesn't have such grammar and nobody would create it only for private fields

The closest solution that I can think of to the current behavior for regular fields and in operator, and something that may look nice with future shorthand proposals is #'x' in obj because it is literally like 'x' in obj but with a private sign and at the same time it opens potential ways for symbol manipulations based on string manipulations that we already have in EcmaScript

[bmeck]

@Alexsey I'm not sure I understand, but that also seems a bit off topic for this issue at least. Maybe open a different issue so we can get some better insight into what is being discussed. I in particular don't know if you mean symbol in the grammar sense or Symbol the JS type.

[ljharb]

The in solution reached stage 2, with the understanding that #foo → this.#foo shorthand would be precluded.