James M Snell

Electron's use doesn't count? At this point I'm not comfortable lifting my -1 on this. I think it should go through at least a deprecation cycle (deprecate now, removed only...

From a language-level perspective, I think it's better if we defined the mechanism as a cancelation/abort protocol in the language... of which `AbortSignal` could be update to be / considered...

> ... also, your implementation ends up still using the addEventListener Only within a hypothetical impl of the abort protocol in the existing `AbortSignal` machinery. That would not be an...

Symbol vs Not-a-symbol isn't that important to me. I'm good with either. More focused on the overall pattern than the particular color of the bikeshed ;-)

That and we'd be sure to define it (in the language) as a protocol that is not dependent specifically on using `AbortSignal`/`AbortController`. I want to make certain that it is...

Overall I think this is a fine addition. I'm not sure how much of a priority implementation would be in non-browser runtimes like Node.js, Cloudflare Workers, etc, but I can't...

@annevk: > This would result in information leakage as discussed upthread. I could see something like this working in non-browser environments though. Understood. As long as it's not forbidden by...

Good idea. This can be addressed by defining an "as:resultOf" property that is the reverse of "as:result"

> When the users do need external memory tracking for heap snapshots, they could pass a CLI flag like --track-external-memory or call a JS API v8.startTrackingExternal, at an overhead to...

That's fair. Hmm... then yeah, an option to opt-in would be good. I think in parallel it would be good to try to see if we can cut down that...