Joe Pea

Of course, I know I can work around it with a convoluted class decorator + getter decorator setup, but it is definitely not ideal. I don't want to have to...

Babel's behavior is the ideal default. Having a getter and its decorator break due to a private field ***in the very same class*** is a bad experience.

> That seems like it'd allow you to easily write a class constructor that interacts with subclass constructors after they've run, If you mean this, ```js function getterDeco(_, context) {...

(I reported the Babel bug, - https://github.com/babel/babel/issues/16188 which I wish was not a bug but the default behavior)

I'm not sure what you're getting at, but getter decorators have `context.addInitializer` to run an initializer before field initializers. I want to run a getter initializer _after_ field initializers.

The suggestion of using a class decorator @ljharb also means that user code in the user's `constructor` body will not be operating on the desired state of the instance, only...

> I’m not sure what you mean by “reliable”; can you elaborate on your use case? If a user uses a decorator, they might want to write code in their...

> Wouldn't this be fixed by #513 ? @justinfagnani If that applies for getter/setter initializers, then yeah, otherwise no. But based on conversations, it seems like we really need more...

> Decorators on instance things are available after a base class constructor, and after super in a derived class constructor. That’s pretty intentional and unlikely to change. I don't think...

@rbuckton's "bucket" idea, - https://github.com/tc39/proposal-decorators/issues/465#issuecomment-1924510021 is essentially asking for the same thing in a different way, if I'm not mistaken. The example in the OP throwing a runtime error seems...