TC39 Delegates on 2022-04-08

05:53	<Jack Works>	I think the issue with using AbortSignal for proxy revocation is the async callback nature of EventTarget. When you revoke a proxy you want it revoked immediately. Yes, a proxy can check if the AbortSignal has been aborted when the proxy is used, but that still introduces GC issues. it's not observable in the user land. so "check signal when use" is equal to "GC on aborted"
05:55	<rbuckton>	I took another look at the DOM spec. "abort algorithms" that are added by the Host (not by the user) are synchronously executed and aren't part of the `abort` event dispatch.
05:56	<rbuckton>	I'm not sure what you mean by "not observable in user-land". If I create a function closure over an object graph that takes up a lot of memory and add that closure to an AbortSignal, the AbortSignal will hold the whole object graph in memory as long as the abort signal is alive, even if the signal is already aborted.
06:06	<Jack Works>	For the massive proxy revoke proposal, we don't need (and don't want) a callback (for each proxy). The RS in the spec will be: next time when the proxy is accessed, check the AbortSignal flag, if aborted, revoke it now. But for the Proxy revoke, it is just drop the Proxy.[[Target]] and Proxy.[[Handler]], which means once it is aborted, the engine can do GC immediately (no need to "check the AbortSignal flag on the next access" so there is no memory leak).
06:35	<Ashley Claymore>	If the main goal is reducing revoke function allocations. Could the API be: `let [proxyFactory, revokeAll] = Proxy.collection(); let p = proxyFactory(t, h); revokeAll(); Array.isArray(p); // Error!`
06:36	<Ashley Claymore>	That way GC could be specced that the references are dropped immediately, but if that actually happens is an implementation detail (best effort)
07:06	<annevk>	rbuckton: I have to say I don't understand the hangup around event listeners. You'd only add an event listener to an AbortSignal if you implemented the aborting in userland. Web platform features use "abort algorithms" instead.
07:35	<rbuckton>	And I imagine the web platform has reasons it depends on synchronous dispatch of "abort algorithms"? What I don't understand is why only the web platform has that privilege while user code has to rely on asynchronous notification.
07:40	<rbuckton>	My other concern is that an AbortSignal can only be aborted once, but an `abort` event can be raised many times (even if only once by the system) due to dispatchEvent. Unlike how `Promise` ensures callbacks are evaluated once, an `abort` event could theoretically be executed multiple times, and most `abort` handlers probably aren't written to be robust enough to handle that case.
07:41	<rbuckton>	So my concern is that the mechanism is inconsistent and fragile, and works until it doesn't. The web platform doesn't have to worry about any of this because internally it gets to do the right thing (synchronous "abort algorithms" that are only executed once). User code isn't so lucky, and that's 90% of my use case for cancellation.
09:57	<Jack Works>	If the main goal is reducing revoke function allocations. Could the API be: `let [proxyFactory, revokeAll] = Proxy.collection(); let p = proxyFactory(t, h); revokeAll(); Array.isArray(p); // Error!` Interesting, maybe we can do this
17:02	<shu>	checking my memory because the notes don't seem super clear: for `toSorted()` in the change array by copy proposal, the consensus is that `toSorted()`, unlike `sort()`, does not distinguish holes from `undefined`
17:02	<shu>	is that right?
17:02	<annevk>	rbuckton: asynchronous? Event dispatch is synchronous.
17:02	<shu>	cc Ashley Claymore for `toSorted()` question
17:03	<nicolo-ribaudo>	You remember correctly: toSorted always performs Get without checking if it's an own property
17:04	<shu>	thank you
17:08	<annevk>	rbuckton: synthetic events are an interesting concern. I don't think it has been a problem in practice. In general the platform has many such one-off events. And it's not that hard to do the right thing in userland given the features that exist around event listeners.
17:32	<shu>	hm how do i test for the difference between skipping holes and not skipping holes without using a Proxy with a [[HasProperty]] trap?
17:33	<shu>	the special `undefined` handling in sort() is stumping me
17:49	<Ashley Claymore>	If you put something on the prototype?
17:49	<Ashley Claymore>	Also there shouldn’t be holes in the newly created array
17:50	<Ashley Claymore>	just more undefineds at the end
17:50	<shu>	how do you test by putting something on the prototype?
17:50	<shu>	[[HasProperty]] looks through the prototype. the check isn't a "has own" check
17:54	<Ashley Claymore>	Ah yes ofc.
17:55	<Ashley Claymore>	So [,,].toSorted()
17:56	<Ashley Claymore>	Should return [undefined, undefined]
17:56	<Ashley Claymore>	But if want to be sure it didn’t check there was the property then I think you’re right that would need a proxy
17:59	<Ashley Claymore>	If useful Nicolò has test262 test here: https://github.com/tc39/test262/pull/3464
21:23	<ljharb>	shu: https://github.com/es-shims/Array.prototype.toSorted/blob/main/test/tests.js#L137-L149 (copied from nicolo's PR and ported to tape)