TC39 General
2026-04-17
plaintext logs
prev next
source on github
13:53
<snek>
building a little display to replace the paper calendar in my kitchen and it is truly incredible how easy temporal has made this
13:53
<snek>
what a beautiful api
14:00
<Caio Lima>
Do you mind sharing a bit more what makes you feel that it's easier? How would the alternative be without Temporal?
14:01
<snek>

well i start with this code

  const now = Temporal.Now.zonedDateTimeISO();
  const startOfWeek = now.subtract({ days: now.dayOfWeek - 1 }).startOfDay();
  const endOfWeek = startOfWeek.add({ days: 7 });
14:01
<snek>
i have no idea what the alternative would be, i'd have to search for a library i guess
14:02
<snek>
also being able to calculate a duration from a calendar event and format it in a human readable way
14:03
<snek>
actually i can just send this i guess https://gist.github.com/devsnek/f8d7c3afb1e76973c4e61628131787c9
14:04
<Caio Lima>
Oh nice!
16:56
<Mathieu Hofman>
bakkot: Thanks so much tackling promise leaks in v8. This has been plaguing the community (really in all engines I've tested) for so long without them realizing.
16:57
<Mathieu Hofman>
FWIW, here is a gist for a crude test I wrote 4 years ago to check the behavior of various engines in different scenarios: https://gist.github.com/mhofman/e4031aa4cd2375d0f151f62691724475
17:04
<bakkot>
I would expect SM not to leak just based on looking at the code
17:04
<bakkot>
Would be interested to know if it actually does
17:04
<Mathieu Hofman>
When I thought about it last time, I was actually thinking there may be one legitimate case where retaining the promise might be worth it, but it's arguable: when the resolver is held but the promise hasn't been settled yet, and the promise had reactions registered before being dropped. Keeping the promise alive indicates work can still be trigger through what the promise once represented.
17:05
<Mathieu Hofman>
This was 4 years ago, maybe things have changed
17:58
<Mathieu Hofman>
Looking back at this I think there are possibly 2 other cases compared to what you're trying to solve in your change: - the resolvers should never be held by the promise itself - dropping an unsettled promise while keeping its resolver doesn't need to hold the promise. One could argue that if the promise has reactions, it could be held in that case.
17:58
<Mathieu Hofman>
But you're right, SM does drop settled promises, and did already 4 years ago
18:00
<Mathieu Hofman>
JSC and XS, at least 4 years ago had the same behavior as V8
18:07
<bakkot>
  • dropping an unsettled promise while keeping its resolver doesn't need to hold the promise. One could argue that if the promise has reactions, it could be held in that case.

certainly if it has reactions it needs to be held, but also it needs to be held for the unhandled rejection event, so I think that one is unavoidable

18:08
<bakkot>
I mean you could do a bunch of complex wiring to avoid actually holding the reified object but it would be complex/slow, so I'm not surprised no one does (oh, no, not even that, because the PromiseRejectionEvent holds the Promise)
21:11
<Mathieu Hofman>
> if it has reactions it needs to be held, but also it needs to be held for the unhandled rejection event, so I think that one is unavoidable Good call! Forgot about that one. Confirms my intuition it should be held on that case
21:54
<snek>
does it need it for unhandled rejection?
21:54
<snek>
i think you could just synthesize a new one in that case
21:55
<Mathieu Hofman>
Depends on the host really. But the web does expose the promise that was rejected
21:55
<snek>
if the only reference was the resolve fns though, you can just make up a new promise object in that case i think
21:55
<Mathieu Hofman>
A new one might be surprising. I could imagine some system tracking the identity of created promises
21:56
<snek>
mmm
21:57
<snek>
let map = new WeakMap();
onunhandledrejection = (e) => console.log(map.get(e.promise));
map.set(new Promise((_, r) => queueMicrotask(r)), 1);
21:58
<snek>
i guess the question is what this does
22:00
<Mathieu Hofman>
Replace that with an error object created at the same time as the promise and you can get diagnostics on where the rejected promise was manually created