proposal-decorators icon indicating copy to clipboard operation
proposal-decorators copied to clipboard

`in`/`access.has()` for `accessor` elements before/during initialization

Open miyaokamarina opened this issue 2 months ago • 1 comments

The current spec and impls assume that in/access.has() for accessor elements work similarly to plain get/set elements. I.e., name in this is true before/during the accessor initialization, access.has() is true in the initializer function, etc.

On the other hand, if I understand the motivation of accessor elements correctly, they are intended to work almost identically to ordinary fields; i.e., they are enumerable, they have shared initializer evaluation order with fields, and everything else except the property descriptor and storage mechanism. According to that logic, in/access.has() should be false before/during the initialization.

(Looks like the current behavior is somewhat easier to implement, but not significantly harder than field-like one)

miyaokamarina avatar Dec 16 '25 12:12 miyaokamarina

I agree the rationale for current orderings is not necessarily intuitive, however acessors create prototype descriptors, which must already exist after the class is defined (before any instance is ever created). In that case, the in operator must necessarily always return true in a constructor. It's is a concrete difference from fields, regardless of the ordering.

This is necessarily true:

class MyClass {
  accessor foo = 123
}

console.log("foo" in MyClass.prototype) // true

// only now is the first instance created:
new MyClass()

TS playground

trusktr avatar Dec 17 '25 23:12 trusktr