Move accessors to separate proposal

[Haringat]

This proposal is about decorators and not inherently about accessors and does not imply their presence (either one, both or none could be included in the language), so the accessors so that discussion about one part does not block progress on the other one.

[rektide]

Getters/setters are in EcmaScript 6, from June 2015.

Just one random person's view, but imo we can & should build new specifications with the assumption that longstanding language features are present & implemented.

[ljharb]

@rektide we do; that has literally nothing to do with this issue. The OP is saying that accessor support is more contentious and thus would slow the proposal. (I’m not agreeing or disagreeing with that stance; just explaining it)

[pzuraq]

This proposal will likely not advance without the accessor keyword. There are many key use cases which require the ability to intercept access to fields, which is why this keyword was added. That said, we could potentially break it out so that the accessor keyword can be discussed independently and advance to stage 4 prior to this proposal.

[Haringat]

@pzuraq would it not be possible to intercept access to fields using getter/setter decorators? I honestly have a hard time understanding the difference between

class X {
    @myDecorator
     accessor x;
}

and

class X {
    #x;
    @myDecorator
    get x() {
        return this.x;
    }
    @myDecorator
    set x(x) {
        this.x = x;
    }
}

except that the latter is more busywork. That getters and setters are referred to as "accessors" does not help the matter.

[pzuraq]

@Haringat accessor decorators typically rely on the ability to entangle state between the getter and setter. So your example would look more like:

const dec = myDecorator()

class X {
    #x;
    @dec
    get x() {
        return this.x;
    }
    @dec
    set x(x) {
        this.x = x;
    }
}

For every single decorated field. This would be a very bad DX and would make adopting decorators very difficult for many existing frameworks that rely on this functionality.

As it stands, the accessor keyword is still part of the proposal, and the proposal has advanced to stage 3, so I don't believe there is really an issue with the keyword being included in the base proposal. If it does end up being contentious when we try to move forward to stage 4 then I plan to break it out into a separate proposal and advance it prior to decorators, as mentioned above.

I'm going to close this issue for the time being, as it is not a change we intend to make.