Splitting this proposal into two

[chicoxyzzy]

Do you mind to split this proposal into two different, e.g. class fields and static properties? AFAIK there is nothing wrong about static properties so no reasons for them to be blocked by other one at stage 1 and it can move to stage 2 or even stage 3.

[dandelany]

:+1: It certainly seems that there are two issues at play here: "static properties" which is entirely uncontroversial, but depended on by a great many React developers (for nicer ES6 propTypes); and "instance properties", which is (rightfully) a hot topic, but from a practical stance, currently used by very few people. It would be great to get the former advanced towards approval - I would bet that this proposal alone is why many developers are using the babel Stage 0 preset, and many of them would rather move that up a notch or two. Thanks!

[ljharb]

@dandelany you can use specific proposals without opting into all of a stage's presets, so I don't think that's a strong argument :-)

I'd love to see static advance, but both static and instance properties will need to address what this means, so I don't think this can be split at this time.

[dandelany]

Of course you can, but the sad fact of the matter is that most devs don't because they are lazy :) I'm just saying that, from a practical standpoint, it would be nice to simultaneously acknowledge a de facto standard and encourage devs to use more stable stage presets by moving static along, if at all possible.

I'm not sure I understand why a proposal for static properties would have to weigh in on the meaning of this. But I trust that you understand the situation far better than I do :)

[ljharb]

A specific example is static singleton = () => new this;. What does singleton() return?

[dandelany]

Ah, I see, thanks. Good concise example of the problem.

[mischkl]

+1 for splitting the proposal. It seems like static properties could get approved faster that way. Even though I am also quite looking forward to class fields, after having used them in TypeScript.

[jeffmo]

I had originally planned to split this proposal into 2, but at this point I think most of the remaining questions apply to both static and instance fields (and it would be a shame to ship one with premature expectations about the other that lead to subtle inconsistencies for the long term):

• Should initializers be set using [[Set]]? Or DefineProperty?
• Should fields be set as configurable? or non-configurable?
• Should we tweak the syntactic token to look less like assignment? (leading idea: :=)

Fortunately, both of this proposal is moving along nicely with the committee.