TC39 Delegates on 2026-06-08

05:19	<bakkot>	today I needed a `Set.prototype.iteratorFrom` method, which I am pretty sure most implementations could do efficiently and which definitely cannot be done efficiently in userland. (that is: you give it an element in the Set, it gives you an iterator for that Set except advanced to point to that element.) thoughts? too obscure?
06:30	<Mathieu Hofman>	today I needed a `Set.prototype.iteratorFrom` method, which I am pretty sure most implementations could do efficiently and which definitely cannot be done efficiently in userland. (that is: you give it an element in the Set, it gives you an iterator for that Set except advanced to point to that element.) thoughts? too obscure? There recently was a related request on discourse that I had a hard time finding the use case justified.
06:31	<Mathieu Hofman>	But different enough I suppose. That request was about indexed access.
08:10	<Ashley Claymore>	https://es.discourse.group/t/map-and-set-getters-to-give-a-way-to-get-an-item-at-an-order/2541/33
13:32	<bakkot>	That one also isn't actually implementable efficiently
13:32	<bakkot>	If it were I'd be all for it
15:15	<linus>	would anyone be upset if we declare merged tests to be a stage 3 entrance criteria? I understand it's not great from a champion perspective if they've done the tests, but from an implementer perspective i don't consider an unreviewed test262 PR sufficient. not everyone uses a vendored copy of test262 that supports pulling in unmerged tests and in particular things like test262.fyi won't be able to show implementation support if there are no tests on main
15:15	<linus>	currently affects several stage 3 iterator proposals
15:40	<bakkot>	I would prefer that we say that test262 tests can be merged as long as they have been reviewed by at least one delegate
15:41	<bakkot>	I am happy to review some test262 tests so that proposals can advance (and have done so for the iterator proposals), but that only matters if they actually can advance given my review
16:05	<Michael Ficarra>	@linus I would only support that if we lowered the bar for merging to test262, as @bakkot suggests
16:06	<Michael Ficarra>	I am not willing to grant the test262 maintainer group the ability to (with good or ill intent) indefinitely hold up any proposal
16:07	<Michael Ficarra>	IMO the purpose of that group should be maintaining the harness and keeping the repo orderly, not reviewing test PRs for correctness or exhaustiveness
16:08	<Michael Ficarra>	reviewing test PRs is our shared responsibility
16:56	<linus>	FWIW the process doc already says: During Stage 2.7, Test262 tests should be authored and submitted via pull request. Once it has been appropriately reviewed, it should be merged to aid implementors in providing the feedback expected during this stage. so I'd wouldn't say it's unreasonable for someone to block a proposal over unmerged tests today 🤷
16:56	<linus>	but i support whatever process change improves the situation for implementers