2026-09-01 [14:35:03.0258] exactly, same 2026-09-05 [17:49:04.0708] Wanted to get some opinions on some far-too-common promise patterns to see if folks might consider them worth addressing. Both minor but exceedingly common. 1. The evil terrible empty catch handler... `promise.catch(() => {})` ... done to suppress unhandled rejections when we don't actually care about rejections on those promises. Several web standard specs specifically indicate that rejections on certain promises should be marked as handled and V8 and other engines have native ways of marking these, but in JS all we have is adding the catch handler... which ends up creating another promise... 2. The never resolving promise... `await new Promise(() => {})` For both, it might be nice to provide some syntactic sugar... ``` promise.markAsHandled(); // works on the current promise, no new promise created await Promise.never(); // or maybe even Promise.never as a singleton that never settles ``` Both quite simple but useful [18:53:53.0739] Seems a shame engines can't just optimize the specific `.catch` pattern but yeah something like that seems useful [18:54:20.0019] much less sure about the never-resolving promise thing, that has never come up in my experience though mine is not necessary representative [19:32:27.0206] I use the never resolving promise pattern quite often while debugging automated test cases, in order to pause the execution and investigate the state. for this case, it might make more sense to provide the feature in the test harness tho [20:00:16.0374] Yeah, comes up nearly exclusively in tests (the never resolving promise). That one probably isn't worth doing anything with because of that... [20:00:36.0191] but the empty `catch(() => {})` comes up WAY too often [22:33:12.0034] i mean, unhandled rejections are a normal part of the language, and it really sucks that both the web and node turn that into a failure mode [22:33:31.0951] imo that's the reason it comes up, because implementations introduced an artificial/unnecessary failure mode [23:25:02.0375] Why not allow for an argument-less `.catch()` instead of adding a new method? [23:48:51.0656] Because that would still create a new promise [23:54:21.0186] Not if argument-less catch returned void. But it feels like a footgun [23:58:19.0285] Yeah I don't think we'd want to overload the return type like that [06:10:41.0734] Yeah, a polymorphic return would make me even more sad than an empty catch handler [11:45:48.0768] I like the Promise.never singleton promise.ignore() would be my naming choice instead of markAsHandled [11:54:22.0902] Ignore kind of implies no handlers will be invoked, to me [11:56:23.0701] A nice quality of Promise.never is that the impl can be optimized to not retain any reactions. Promise.never.then(fn) can be a co-op that does not retain fn at all. [11:56:38.0669] * A nice quality of Promise.never is that the impl can be optimized to not retain any reactions. Promise.never.then(fn) can be a no-op that does not retain fn at all. [12:30:09.0244] I am reminded that some promise implementations that predated native promises had a `.done(onfulfilled, onrejected)` method that had no return value. [12:45:33.0553] from what I can tell spidermonkey at least is capable of not allocating a result when it is syntactically known not to be used, e.g. https://searchfox.org/firefox-main/source/js/src/builtin/Array.cpp#3440-3442 [12:46:15.0220] I don't know if it does this for `.then`/`.catch` but I don't see any reason why it couldn't [12:46:45.0620] though I guess the unhandled rejection handler makes that tricky, hm [12:48:23.0781] actually it looks like they do: https://searchfox.org/firefox-main/rev/0271096efe3ea9e8c9a5479f26774f1842ef0585/js/src/builtin/Promise.cpp#7358 [12:49:28.0743] oh and they just materialize a promise on the fly for the unhandled rejection handler if it was optimized out, very nice https://searchfox.org/firefox-main/rev/0271096efe3ea9e8c9a5479f26774f1842ef0585/js/src/builtin/Promise.cpp#4100-4107 2026-09-08 [23:39:04.0390] Hi all! Riki from Sony Interactive Entertainment here 👋 🇯🇵 We’re excited to welcome TC39 back to Japan in about 3 weeks! Just a friendly reminder to fill out the [In-Person Registration Form](https://forms.gle/PwJ5b6NUTqkjaiBn9) if you’re planning to attend in person. **Registration is a MUST**, and there may be some very serious consequences™ if you show up on the day without letting us know 👹 Looking forward to seeing everyone in Japan ♥️ [23:40:25.0661] * Hi all! Riki from Sony Interactive Entertainment here 👋 🇯🇵 We’re excited to welcome TC39 back to Japan in about 3 weeks! Just a friendly reminder to fill out the [In-Person Registration Form](https://forms.gle/PwJ5b6NUTqkjaiBn9) if you’re planning to attend in person. **The deadline is one week from today**, so please make sure to register by then! Registration is a MUST, and there may be some very serious consequences™ if you show up on the day without letting us know 👹 Looking forward to seeing everyone in Japan ♥️ [07:53:06.0018] how about `.suppress()` [10:15:33.0514] suppress does not come across as meaningful to me. "unhandled" is common terminology for promise rejections, making "mark as handled" fairly intuitive [13:58:19.0009] How about p.handle() defined as a then with two optional args and a void return value. Calls the eight callback if present to handle, disregards its return value and doesn't create a new promise [13:58:51.0904] * How about p.handle() defined as a then with two optional args and a void return value. Calls the right callback if present to handle, disregards its return value and doesn't create a new promise [14:38:41.0253] I guess I'm just not sure why it's necessary to re-architect a simple approach that already exists [14:40:05.0162] it's really literally just putting a wrapper around an existing embedder function that is already called "MarkAsHandled" https://v8docs.nodesource.com/node-25.0/d3/d8f/classv8_1_1_promise.html#a797ac702cb8e94a7bf117e9d3eeb55bc [15:03:47.0174] Embedder functions are generally made for convenience of a particular engine with very little thought given to their design, and are also not exposed to 99.99%+ of users. [15:04:46.0146] It's certainly possible for an such a thing to have landed on a good design, but there's not much reason to take them as precedent except insofar that they establish a thing is possible [15:11:55.0935] Yeah I know :-) I'm just not seeing any argument that convinces me that it's not a good design? If that make sense? Like I'm seeing bike shedding but no explanation why the current approach is not ideal. [15:17:08.0337] i mean the current approach isn't ideal because the current reality isn't ideal. unhandled rejections are supposed to be fine. [15:19:49.0522] Well, yeah.. ;-) ... accounting for that however [15:23:04.0872] whenever there's a proposal I think it makes sense to have a period of tossing out random related ideas before settling on a design even if there is nothing particularly wrong with the original proposal, because maybe there's something better [15:23:17.0855] but you have to actually spend a while playing with possibilities to know this [15:23:33.0126] Fair [15:27:05.0012] Let's not worry then what we call it or what the shape exactly is. Not discounting @ljharb's comments there about the situation being unfortunate, do we think there's enough of a motivation here for me to bring a Stage 1 proposal? [15:28:09.0243] * Let's not worry then what we call it or what the shape exactly is. Not discounting @ljharb's comments there about the situation being unfortunate, do we think there's enough of a motivation here for me to bring/ask for a Stage 1 proposal? [15:28:39.0500] the only benefit over `.catch(() => {})` is that a noop isn't needed? [15:30:23.0600] * the only (concrete) benefit over `.catch(() => {})` is that a noop isn't needed? [15:31:10.0316] No no-op function, no new returned promise. There's also the consideration that await p.catch(()=>{}) does not propagate the rejection to the await. But markAsHandled(p); await p; does propagate to the await still [15:31:56.0905] Sure you could p.catch(...); await p; but the small footgun is still there [15:33:41.0218] That's super minor but just illustrates that the whole motivation would be avoiding small footguns. They can be worked around already. This is why I'm just asking the question about whether there's enough motivation to even bring it 2026-09-11 [01:04:43.0759] Olivier Flückiger: Hello! I see [the V8 bug declaring let/const to be slower than var](https://issues.chromium.org/issues/42203665) has been closed. Does this mean you believe they now have performance parity? (This is a perf issue Shu previously brought to the committee when he worked on V8)