Extracted from the proposal [1]:
> Instead of waiting for the community to define and agree upon decorators for these purposes, why not define them now?

In my opinion this is not how things should be done, in my opinion we
actually should follow user-land patterns and help modifying/extending
the language in this patterns pain points. We saw that in almost every
new feature in the language since Harmony (not a coincidence, it's was
actually decided to be this way), community agreement is a important
factor in the process (I really don't know why it's not in the TC39
process document [2], maybe is implied?). A lot of problems in
Javascript ~and probably all other languages in existence~ arose from
expected usefulness, just to be tagged as a foot gun or bad design by
the community, and not used at all.

That being said, I think decorators already provide all the need for
this "runtime-modifiers" keywords, and new keyword-like modifiers will
only add complexity to the language, as we would have 2 declarative
ways of doing the same thing (or worse, the community decide in a
different behavior for the analogue decorators, and probably one of
the ways would be discouraged and become spec garbage).

PS.: Sure there are cases were the community is really divided and
things don't move because of that, and some of this cases are merged
in the spec without total agreement at the end. But in my opinion this
slow process and discussion is a good thing, we cannot merge something
just to because it seems like a good feature. Also I'm not a TC39
member, it's my opinion based in similar discussions in the past,
maybe some real member can clarify it better or correct me if I'm
wrong.

[1] https://github.com/rdking/proposal-common-member-modifiers#motivation
[2] https://tc39.github.io/process-document/
Em dom, 2 de dez de 2018 às 04:49, Ranando King <kingmph at gmail.com> escreveu:
>
> Since some form of data is going to land in ES class syntax, it would be a good idea if the capabilities of a property descriptor were also exposed for all public properties.
>
> https://github.com/rdking/proposal-common-member-modifiers
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



-- 
Atenciosamente,

Augusto Borges de Moura

Extracted from the proposal [1]:
> Instead of waiting for the community to define and agree upon decorators for these purposes, why not define them now?

In my opinion this is not how things should be done, in my opinion we
actually should follow user-land patterns and help modifying/extending
the language in this patterns pain points. We saw that in almost every
new feature in the language since Harmony (not a coincidence, it's was
actually decided to be this way), community agreement is a important
factor in the process (I really don't know why it's not in the TC39
process document [2], maybe is implied?). A lot of problems in
Javascript ~and probably all other languages in existence~ arose from
expected usefulness, just to be tagged as a foot gun or bad design by
the community, and not used at all.

That being said, I think decorators already provide all the need for
this "runtime-modifiers" keywords, and new keyword-like modifiers will
only add complexity to the language, as we would have 2 declarative
ways of doing the same thing (or worse, the community decide in a
different behavior for the analogue decorators, and probably one of
the ways would be discouraged and become spec garbage).

PS.: Sure there are cases were the community is really divided and
things don't move because of that, and some of this cases are merged
in the spec without total agreement at the end. But in my opinion this
slow process and discussion is a good thing, we cannot merge something
just to because it seems like a good feature. Also I'm not a TC39
member, it's my opinion based in similar discussions in the past,
maybe some real member can clarify it better or correct me if I'm
wrong.

[1]: https://github.com/rdking/proposal-common-member-modifiers#motivation
[2]: https://tc39.github.io/process-document/