| 07:33 | <bakkot> | some discussion from whatwg about exposing structured clone: https://github.com/whatwg/html/pull/3414#issuecomment-853998618 |
| 08:11 | <DerekNonGeneric> | funny, i was just reading the C++ impl in SM https://searchfox.org/mozilla-central/source/js/src/vm/StructuredClone.cpp |
| 08:23 | <DerekNonGeneric> | unclear if the ask is simply to expose structuredClone(value, options) or what else that might entail, but seems like it would be really handy for it to be available somehow https://whatpr.org/html/3414/structured-data.html#structured-cloning |
| 15:25 | <shu> | does anyone have recollection of a synchronous Promise introspection API? e.g. something that gives back stuff like { state: "fulfilled", value: ... }? |
| 15:30 | <yulia> | something like promise.isFulfilled or like getting the value back, or just introspection? |
| 15:30 | <yulia> | i was talking earlier about a similar api with someone as an alternative for the deferred eval thing |
| 16:06 | <littledan> | yulia: I think we tend to view this as violating some kind of fundamental principle |
| 16:09 | <littledan> | maybe as part of https://w3ctag.github.io/promises-guide/ but I'm not sure which part |
| 16:15 | <bakkot> | I vaguely recall something to this effect but can't find a proposal. Closest I can find is https://github.com/tc39/proposal-async-await/issues/16 and some discussion in https://github.com/tc39/notes/blob/master/meetings/2015-07/july-30.md#64-advance-async-functions-to-stage-2 |
| 16:27 | <littledan> | this was also discussed in the context of cancellable promises |
| 16:39 | <shu> | i'm thinking of getting both state and value back |
| 16:40 | <shu> | the specific context is application-level optimization opportunities to skip microtask ticks |
| 16:41 | <shu> | my initial take was along the lines of what littledan said with violating some kind of anti-Zalgo principle |
| 16:42 | <shu> | bakkot: thanks for that thread, the reason that killed that transformation idea is exactly the motivation for wanting it |
| 16:43 | <shu> | though in this case, there's no problem in that the buck is passed to the application. it's up to the app to write stuff like let x = promise[inspectSymbol].state == "fulfilled" ? promise[inspectSymbol].value : await promise; |
| 16:43 | <shu> | err |
| 16:45 | <yulia> | yeah this was my reaction as well, but this is what the write up was from that alternative: https://github.com/tc39/proposal-defer-import-eval/blob/main/alternatives.md#delegating-work-to-blocking-workers |
| 16:46 | <yulia> | i forgot exactly what that looked like, but its a blocking api. I don't think it is realistic but it keeps coming up |
| 16:47 | <shu> | blocking seems different to me than this, which is fine with async waiting, but wants to know when it would be wasteful |
| 18:39 | <bakkot> | there was also https://github.com/tc39/proposal-atomics-wait-async/pull/30 |
| 18:39 | <bakkot> | I think for the vast majority of promises the single microtask tick is going to be irrelevant next to the time it takes for the promise to settle in the first place |
| 18:48 | <Jamie Kyle> | Does having the state of the promise available synchronously have a huge benefit over checking it in one-tick: https://gist.github.com/jamiebuilds/44f469bece4d2c5b45daa3031e48232d |
| 19:35 | <shu> | bakkot: i agree with that intuition, that for the majority of cases it doesn't matter |
| 19:35 | <shu> | bakkot: i've gotten feedback from internal product teams that it very much does matter, to the extent that they're not using native Promises directly because of it |
| 19:37 | <shu> | and as you know, i have a soft spot for performance-driven features for minority power user apps :P |
| 21:30 | <bakkot> | shu: unrelated, I'm thinking about proposing ArrayBuffer.fromBase64 and ArrayBuffer.prototype.toBase64. thoughts? |
| 21:34 | <shu> | bakkot: common, onerous enough to write in userland, not really any room for "innovation" or different ways to design it. ticks all the boxes for me for standardizing, i'm positive on it |
| 21:34 | <shu> | it's too bad we'll have competing conventions with TextEncoder/Decoder, but what you gonna do |
| 21:35 | <bakkot> | those don't do base64 though |
| 21:35 | <bakkot> | afaik |
| 21:35 | <bakkot> | and aren't going to because base64 isn't text |
| 21:35 | <shu> | i know, i meant more like those are standalone classes, not methods |
| 21:35 | <shu> | API surface convention |
| 23:03 | <bakkot> | ah, sure |
| 23:03 | <bakkot> | those are a weird convention though |