add agenda item for Float16Array for stages 2 and 3

[bakkot]

No description provided.

[phoddie]

I'm unsure if advancing a proposal two stages in a single meeting is consistent with the stage process. I acknowledge that it may not be expressly disallowed by the process text, but it seems to side-step the deliberate pace intended by the stage process.

[leobalter]

IIRC, this already happened in the past, but I also remember the message was that double advancement could be rejected if a delegate express the desire of keeping the one-step pacing for the proposal to reach better maturity.

At the same time, @phoddie it seems like from your comment this might not be ready for implementation. I'm supporting you here if that's the case.

[ljharb]

it's indeed happened many times before and is often acceptable when semantics are straightforward and noncontroversial, but as @leobalter indicates, it's also totally fine to withhold consensus for two stages at once if there's a reason to go slower.

[phoddie]

it's indeed happened many times before

Thanks, @ljharb. While I've not attended everything TC39 meeting in the last 5 years, I've been at plenty. And while my memory is far from perfect, I don't recall this happening. I do recall it being proposed a couple times. Would you mind citing an example or two?

it's also totally fine to withhold consensus for two stages at once if there's a reason to go slower

Understood and appreciated. Still, this assumes that a delegate who might object is fully engaged with TC39. The reality is that not everyone has time to track every proposal at every meeting. Advancing proposals by no more than one stage at a meeting gives more delegates an opportunity to provide feedback. That's fundamental to the stage process. And given how controversial proposing a step backwards in the stage process is, a measured paced is all-the-more important.

t seems like from your comment this might not be ready for implementation. I'm supporting you here if that's the case.

@leobalter, thank you. I'm not taking a position here on the proposal itself. At first look, it appears straightforward.

[ljharb]

@phoddie

• tc39/proposals@309b3ac Duplicate named capture groups went from 0 to 2, conditional on spec review
• tc39/proposals@11a2382 Destructuring private fields went directly to stage 2
• tc39/proposals@ea97e3d Object.hasOwn went directly to stage 2
• tc39/proposals@d348990 hashbang grammar went directly to stage 2
• tc39/proposals@812c9f3 ArrayBuffer transfer went directly from inactive to stage 2
• tc39/proposals@a669637 Promise.prototype.finally went directly to stage 2
• tc39/proposals@8a333a1 optional catch binding went directly to stage 3

That's all I could find with some trivial code searches of the proposals repo.

[phoddie]

Thanks, @ljharb.

FWIW – none of those went to Stage 3 or Stage 4 in a single meeting (with one small exception). It still feels like a stretch to leap from "The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns" to "The solution is complete and no further work is possible without implementation experience, significant usage and external feedback" in one meeting.

It was my mistake to raise this concern here. This isn't the appropriate forum. Thank you for your patience.