Do not hesitate to make design changes just because Chrome has shipped

[jhpratt]

From the README:

Public fields are shipping in Chrome 72 with [[Define]] semantics, and this decision on semantics is unlikely to be revisited.

As I stated on January 4,

TC39 could certainly request they hold back until major issues are at least resolved. Of course the Chrome team doesn't have to listen, but they could then be shipping what will become a nonstandard implementation.

I don't believe that we should be content to let the Chrome team ship something that isn't finalized, then likely come back and complain that the standards have changed and their behavior is different (or prevent the spec from changing at all). That's giving far too much power to one entity, and is not how a standards process should work.

it is unacceptable to not even request a vendor hold releasing a feature until major points are decided.

There is still significant disagreement on [[Define]] vs [[Set]], as well as some other points. At least one committee member (littledan, I believe) has stated that they basically agree that [[Set]] would be the correct decision, but it's too late to change it now.

I stand by my previous remarks, and feel it needs reiterating. The committee has to be responsible for their lack of action, and it is on them that there may be changes to the proposal, despite the fact that is has shipped in Chrome.

Please do not hold back on making changes because of this. It will forever affect JavaScript.

[bakkot]

All major points are resolved. All minor ones, too. That's what stage 3 means, and why stage 3 is specifically called out in the process document as the appropriate time for vendors to begin shipping implementations.

As I said then:

There has to be a point at which TC39 considers a proposal to be as ready to ship, at which point browsers can start implementing and shipping it. That point is stage 3. This proposal has been at that stage for a while

[rdking]

@jhpratt I know I've seen ljharb make that comment. The problem here is that TC39 has already come to a "concensus". In plain english, it means that those on the board who have dissenting opinions regarding this proposal would still rather see this proposal reach stage 4 than be held up due to its issues. From this perspective, TC39 sees no need to further discuss the merit of their decisions with the community. On the whole, they are now only interested in reaching stage 4, which will likely happen within the next few meetings since Firefox has completed an implementation.

Unlike what @bakkot is saying, it isn't that "all major points are resolved", but rather that those in TC39 with dissenting opinions have conceded their stance in order to favor releasing the proposal. It's not the same as a resolution, but it has exactly the same effect on the community and language.

[bakkot]

@rdking

From this perspective, TC39 sees no need to further discuss the merit of their decisions with the community.

Please don't speak for the committee. This is not true. If there are aspects of this which have not yet been considered, we are always interested in hearing them.

it isn't that "all major points are resolved"

Yes, it is. That's what stage 3 means. Not every detail is as every member would choose it if they were BDFL, of course, but that is true of essentially every proposal.

[rdking]

I have no intention of speaking for the committee. My words are my own, and the words I use are my understanding of things that I have been told by various committee members. There are still standing committee members who do not agree with various parts of this proposal. Is that not true? Yet these committee members are still willing to allow the proposal to proceed to stage 4 unmodified. Is this not also true? This 1 of the possibilities of the nature of the "consensus" that TC39 uses as explained to me by TC39 members.

It was also explained to me that TC39 doesn't use a voting system, but rather a system of tacit agreement by means of absence of veto. This does not align with any of the meanings of "resolve". Please understand that I am a big fan of denotated meaning when I use words. If something I've said is wrong, please correct me. However, if something I've said is wrong, then there is still far too much about the actual proposal process that still needs explaining.

---

Just as a matter of note: Resolution requires finding the solution to a problem. As an example, the choice of set vs define in the minds of some of the TC39 members still doesn't agree with the concensus of the board. To find a "resolution", the opposing members would need to be able to agree that despite whatever opinions to the contrary, one particular option is superior to the other. Instead, unless my understanding is incorrect (if it is, then please correct), for the ones that do not agree with the final decision, they remain silent on the issue not because the decision was the superior choice, but rather because they do not want the argument to further delay the proposal, and they're certain they cannot convince all of their opponents to change sides ( an important requirement since TC39 consensus is a 1-bad-apple approach).

Hope this makes what I said a little more clear. Again, feel free to correct anything I've said.

[ljharb]

Consensus is resolution. It means progress can be made. Universal agreement is not required or expected.

[rdking]

I can accept that if that is how TC39 insists on using the terms. However, please understand that using less-than-clear meanings like this will only invite further confusion from the community.

[bakkot]

Often there are questions in design with fundamentally incompatible possible answers. "Should class fields use Set or Define semantics (or both or neither)" is one of them*. Unless everyone agrees on one particular design to start out with, the only possible resolution to questions of this type is that we collectively pick one which everyone agrees is acceptable, even if some people prefer alternatives (edit: that is, everyone on the committee; we can never get everyone in the world to agree on anything, not even bedrock principles like "don't break the web"). That's what it means for design questions like this to be resolved. That is the usual meaning of the word.

Anyway, this is getting pretty off topic. The OP seemed to be worried about Chrome shipping things when TC39 hadn't yet decided on a design. But we have decided on a design.

* As are, I wish to emphasize, many other questions in many other proposals. This is the usual process for pretty much every nontrivial multiparty design question, not just on TC39 or in language design but in general.

[littledan]

As @ljharb and @bakkot have explained, Chrome shipped this because TC39 made the decision, in collaboration with the community, and stuck with that decision for years of stability of the proposal, advancing it to Stage 3. This was not an intervention by Chrome, but rather implementation following committee decisions. At this point, Firefox and Node.js have also shipped the Define semantics. It sounds like we will need to update the README to clarify the process and directionality of the decision-making here.

[rdking]

@littledan

Chrome shipped this because TC39 made the decision, in collaboration with the community...

What sector of the community precisely? This is important as several significantly sized sectors of the community have been identified that do not agree this proposal should be pushed forward. This is why around a year ago, many of us detractors argued that statistics should be invoked to get a temperature of the community over such a large and controversial issue. I suspect the response would be far more frigid than you anticipate, especially if you expose both the strengths and weaknesses of this proposal.

...and stuck with that decision for years of stability of the proposal, advancing it to Stage 3.

...despite years of arguments about the technical flaws of this proposal that could be corrected with very simple design tweaks, and despite failing to allow adequate time for the community to feel out an implementation before advancing the stage.

As much as you may want to support this proposal by saying it followed the process, you yourself have posted in the past that "the process may have failed." Trying to support the validity of a proposal on the back of a failed process is itself a failure. I've said it to you several times before. You need better arguments. The ones you have are not convincing.