Proposal Status?

[12wrigja]

Was wondering what the status of this proposal was, given that it's not listed on the TC39 Proposals page.. Based on an EDiscuss thread I'm wondering if this has stalled?

[zloirock]

It's listed on the TC39 stage 1 proposals page.

[12wrigja]

Ah thanks!

[zloirock]

@gsathya @Ginden any plans about advancing this proposal? 3.5 years without updates.

[gsathya]

@gsathya @Ginden any plans about advancing this proposal? 3.5 years without updates.

No plans on my end.

cc @bakkot who said he might be interested in taking this up.

[bakkot]

Yeah, I am interested in pursuing this, but don't have time to take it up right now.

The place this got hung up on last time was subclassing, which is somewhat incoherent for builtins in JS at the moment. Ideally we'd figure out what we wanted to do with subclassing more comprehensively so we didn't have to address it on a proposal-by-proposal basis. Conveniently @syg is looking into that, in part. My hope is that we'll have a more coherent vision for how we want to handle subclassing sometime soon, at which point it will (I expect) be a lot less work to advance this proposal.

[zloirock]

@bakkot I know that proposal-rm-builtin-subclassing will break the web, some years ago I explained it some times. Seems to need to write it in the proposal repo.

[zloirock]

tc39/proposal-rm-builtin-subclassing#23

[bakkot]

@zloirock In terms of this proposal it matters less what that proposal does for existing classes than what we decide we ought to do for new classes and methods in the future.

[zloirock]

@bakkot I was just surprised that rm-builtin-subclassing proposal is still being discussed in its current form.

[zloirock]

Also,

If removing Type III and Type IV is not web compatible, this proposal shall be withdrawn.

[Ginden]

@Ginden any plans about advancing this proposal? 3.5 years without updates.

I would like to, but I'm quite blocked - there are conflicting visions of subclassing among TC39 members and it blocks proposal. It's quite similar to status of Set methods.

I was asked to research approaches used by other languages, but there was no followup from anyone.

[Ginden]

@bakkot @zloirock I just got idea - make new methods throw on subclasses with overwritten @@species and let keep/change that behaviour if Restricting subclassing support in built-in methods gets some traction.

I don't think that someone will rely on new method throwing.

[zloirock]

As a temporal option it could work, however, I think that the proper subclassing is required for many cases and here I don't see any alternatives to @@species.

[tintin10q]

How is the state of this proposal at the moment?

[zloirock]

So, Set methods proposal on stage 3 with finished semantics - non-generic methods, without subclasses support, without delegation to basic Set methods (for this), and with support set-like arguments.

I'm not a fan of this semantics, but it's better than no progress.

Accepting this semantics means removing the block mentioned above. Are there any plans to revive and promote this proposal?

[michaelficarra]

@zloirock I think this proposal would probably have to be split into smaller, more focussed proposals to have any shot at advancing.

[Ginden]

@zloirock I started pushing things and creating PRs.

@michaelficarra How would you split it?

[michaelficarra]

@Ginden Pretty much method by method. It's very hard to justify these omnibus proposals. Iterator helpers did it with great difficulty and only by paring it down to just those methods that were already on Array.prototype. Notice that each of the iterator helper follow-up proposals is only proposing 1 or 2 methods that need to be individually justified.

Math extensions was an omnibus proposal which failed. Individually, each of the proposed additions may have found success, but it wasn't sufficient to justify them together with "well, other languages have these". A chain is only as strong as its weakest link, and a proposal is only as strong as its least-justifiable component.