2026-06-01 [12:06:52.0450] ljharb: `x = new Promise(()=>{}); Promise.try(() => x) === x // false` was this discussed? seems like it would be nice if it were `true`, like if you'd done a try-catch with a `Promise.resolve()` in the non-throwy case, to avoid the extra allocation/microtask [12:07:25.0184] it wasn't discussed afaik, and i'd be fine with tightening that if possible [12:07:52.0310] since Promise.resolve offers that semantic it's kind of silly not to use it anywhere else we can [12:08:38.0726] yeah [12:08:45.0196] would clean up some code I'm writing, at least [12:08:59.0754] I bet we could get away with changing that still, it's relatively new [12:10:37.0097] the MDN description of the problem statement certainly makes it sound like it ought to work that way: > You may have an API that takes a callback. The callback may be synchronous or asynchronous. You want to handle everything uniformly by wrapping the result in a promise. The most straightforward way might be `Promise.resolve(func())`. The problem is that if `func()` synchronously throws an error, this error would not be caught and turned into a rejected promise. (but then goes on to give the actual semantics) [12:31:36.0858] I guess if we got https://github.com/tc39/proposal-faster-promise-adoption I might not care; I don't actually care about identity _per se_, just that I don't have to wait an extra tick in the happy path 2026-06-02 [09:45:51.0480] There would still be an additional tick. Right now there are 2 ticks. With your proposed change there are 0 ticks. [09:46:26.0909] (Ignoring the one from the user calling `.then()` on the result, shared by all) [09:46:53.0155] This seems like a good easy optimization. [09:47:08.0124] And matches the special behavior of `Promise.resolve()` [10:58:30.0533] agenda'd https://github.com/tc39/agendas/pull/2111 2026-06-03 [01:00:22.0094] Hello delegates! Please get your transcript edits, summaries, and conclusions written TODAY! **TODAY!** Notes are due from me on Friday. I have put them off as long as I can. Honestly it's not really ideal that I have to cram it all in to one day but as long as everyone else procrastinates I'm kinda stuck 😕 What is a summary? Mostly written before you even present, it summarises the presentation and any interesting details from the subsequent conversation. What is a conclusion? Any decisions that were made at the end of the agenda topic, along with any conditionals or relevant details. And the rest? Find your TLA and make sure everything you said was accurately represented by the transcription. Find conversations you were a part of and see if any missed TLAs (often, but not always, represented by `???`) should actually be credited to you. It's okay to delete, for example, operational conversations that happened in between agenda topics. [01:02:02.0540] And for my sake: If you don't get them done today, it's better you make an attempt at doing them tomorrow than not try at all. It might be too late, but it *might* save me an hour of trying to read a transcript and poorly summarise. Or a future reader an hour of reading just to realise the information they're seeking isn't in that section. [01:05:53.0453] Also, thank you to everyone who's already gotten to this, you're wonderful. [01:27:33.0850] Aurèle Barrière: You're so on top of things that you have _two_ summaries and conclusions. Could you help me understand how to format them? [01:50:01.0476] 2 clicks less to get there in case that's what was stopping anyone: https://docs.google.com/document/d/1NX7d9nxkn_tLglJTn9ZhArBXIcUEM2l5TRedHS8J67I/edit [01:50:21.0744] * 2 fewer clicks to get there in case that's what was stopping anyone: https://docs.google.com/document/d/1NX7d9nxkn\_tLglJTn9ZhArBXIcUEM2l5TRedHS8J67I/edit [01:52:08.0599] We shouldn't link to the notes here [01:52:18.0491] oh wait that link shouldn't be here [01:52:35.0754] Yeah. This chat is public [01:52:37.0767] oops. sorry. didn't know that. [01:52:44.0140] * --- [02:17:39.0395] Fixed. I wrote the summary/conclusion at the bottom and it looks like someone else had already (or has since) written one at the top. They're merged now. [02:18:23.0963] Thanks! We had written one with Clément Pit-Claudel yes! [09:16:58.0713] I really like this Bytecode Alliance AI Tool Use Policy (adapted from LLVM, itself adapted from Fedora Project) https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.md [09:17:45.0382] I think it is aligned with the spirit of our own AI policy, but spells it out in more detail and provides justification [09:18:17.0383] any thoughts on replacing our AI policy with something similar? [09:20:51.0100] Opposed, I don't want to read AI prose whether or not a human vouches for it [09:20:59.0822] Code is a different matter [09:26:53.0941] how about scoped to code contributions? [09:29:16.0873] Our AI policy doesn't technically cover code at all; I might be ok with adding something like the above for code, but most code contributions are test262, and adding more work for test262 reviewers (in the form of more submissions, from contributors using LLMs) is probably an anti-goal [09:29:41.0954] like technically this PR violated our AI policy in its description, but the code contribution did not: https://github.com/tc39/ecma262/pull/3865 [09:32:11.0359] but I don't want to review code contributions that the author did not review themselves [09:33:28.0943] and I think it's a much nicer experience for a contributor to receive an explanation of why exactly that's antisocial and unhelpful behaviour instead of just a sentence or two saying that it's unwelcome [09:51:35.0422] is spec text code? debatable [09:51:55.0893] I agree that it would be good to have something more expansive to point people to though [09:54:36.0370] I automate some writing of test262 tests using LLMs but with my reviewer hat on, I haven't found the output to be good-quality enough to use without me editing it. nonetheless, it's often helpful. I wouldn't want to forbid others from using it responsibly if I believe I can do so myself, however, a large portion of our review backlog consists of LLM-generated PRs adding coverage for fairly low-priority edge cases (which would require deep-diving into the spec to understand if they are really correct) [10:06:19.0960] yeah, I am fine with people sending LLM-authored PRs if they're sufficiently competent but that's not really a policy you can reasonably write down 2026-06-04 [07:41:09.0609] Ecma is still working out our overarching AI policy, but keep in mind that IP is terribly important to be attentive toward in standards and LLMs… do not support that requirement. [08:04:10.0537] Small side note... Keep in mind that Gen AI technologies *are* being integrated into legally protected assistive devices for people with various disabilities. Any AI policy does need to be sensitive to the fact that use of such is protected in most jurisdictions. Most attempts to apply blanket bans on use of AI to generate contributions aren't adequately taking this into consideration [08:06:01.0648] While such use in open source or standards contributions is likely minimal or even theoretical at the moment, it still needs to be considered [08:06:53.0875] (this coming from someone whose arthritis is starting to make it increasingly more difficult to type for long periods of time) [08:22:25.0990] I believe considering LLMs an assisted keyboard is generally helpful in considering the outcomes, especially responsibility for the text produced. [08:27:02.0090] yeah, I've had similar conversations with delegates about our AI policy as currently written, particularly with regard to inclusivity, neurodivergence, and assistive tech. I understand the position of "I don’t want to read AI prose", and I share the same sentiment, particularly with regard to AI slop and/or walls of text. but I think these concerns raise a reason to revisit our policy. the goal being to avoid unintentionally excluding people who use AI or similar tools as assistive technology, including some neurodivergent participants we need to balance concerns about AI generated contributions with inclusivity and reasonable accommodation, not just under the law but also ethically. our policy should target unaccountable or low-effort AI generated contributions without making participation harder for people who need support communicating clearly [09:27:34.0889] I'm a little unclear on how that works. All AI tools operate on a model of taking some machine-readable human-generated input and producing some output. I want to be given the human-generated input instead of the output. [09:29:50.0698] Though of course there is a great diversity of assistive tech, so it's hard to have a completely blanket policy. I agree that having clearer wording about assistive tech would be good, but I don't want it to extend to allowing LLM-authored prose in general. [10:48:35.0177] Thoughts on striking "not the product of large language models (LLMs) or other tools" from https://github.com/tc39/how-we-work/blob/main/AI_POLICY.md? That could be read to suggest we're forbidding all use of LLMs, which is not the intention. So it would read > This policy applies to prose contributions (e.g., ideas, comments, issues, etc.). It does not apply to code contributions, which are evaluated through our review processes. > Prose contributions and comments must be your own writing, not the product of large language models (LLMs) or other tools. Do not prompt an LLM to expand on or explain your idea and then post the output; just provide the idea itself. > Machine translation is permissible, including translation by an LLM, but your use of translation should not introduce any new content. > Similarly, you may use an LLM for proofreading as long as this doesn't add any new content. 2026-06-05 [04:01:05.0362] If anyone is wanting to pitch an adjacent meeting to the September Tokyo plenary (e.g. a TG4 meeting) and would like to gather interest in such an add-on, please let chairs know this week before we publish the interest survey, so that we can add a column. [04:01:48.0731] * If anyone is wanting to pitch an adjacent meeting to the September Tokyo plenary (e.g. a TG4 meeting) and would like to gather interest in such an add-on, please let chairs know by 12th June, (i.e. before we publish the interest survey), so that we can add a column. [07:03:08.0546] Hey (sry it's been a few days) I'm asking myself why this equality should be the case here? In the PR https://github.com/tc39/ecma262/pull/3883 you mention that this better matches intuition, but a Promise.try always wraps (or lifts) its given value. But JS has this quirk that it automatically unwraps a Promise before lifting the value into a new Promise. That's why for me the expectation would be that `PromiseX !== PromiseTry` Why should this be different just for the `try` case? [08:19:40.0089] It matches Promise.resolve, and my intuition is that Promise.try is for cases where you'd like to wrap a possibly-sync function with Promise.resolve but you also want to handle sync exceptions [08:22:52.0095] In other words, while you're correct that JS unwraps a Promise before lifting it into a new Promise, there is nothing that says Promise.try is "lifting the value into a new Promise" - it's really about dealing with _non-promise_ values, and you want it to be as transparent as possible for values which are already a Promise, which is exactly the case for Promise.resolve. [08:26:21.0080] (Your intuition may differ, of course; but also, separately, I think it is more useful if it doesn't re-wrap Promises, because that means you don't have to pay two extra microtask ticks.) [08:42:49.0953] Some of these summaries are somehow both terse and incredibly thorough, nice work everyone [08:47:18.0286] that's exactly what I was going for [08:48:20.0894] yeah, I think this is a good idea, esp because that clause isn't doing any heavy lifting, so removing it doesn't change the meaning of the sentence/policy. I think also considering an explicit carve out for assistive technology would be good. similar to the one for proofreading, this can (should) be very lightweight and not prescriptive [08:49:11.0240] I will try to take a stab at it shortly [09:35:32.0946] Hey all, on meeting planning we don't yet have an Asia host volunteer for 2027. We'd love to get a fresh volunteer host! Please contact the chairs if you would like to start this conversation. [09:35:54.0405] * Hey all, on meeting planning we don't yet have an APAC host volunteer for 2027. We'd love to get a fresh volunteer host! Please contact the chairs if you would like to start this conversation. [09:42:12.0576] I thought that `try` in FP is exactly for lifting the result of an operation (sync or async) into a monad (Either) and thereby dealing with exceptions (Left(error), Right(value) or in JS terms reject(error), resolve(value)). I was under the impression that Promise.try was created with FP as a reference. [09:51:46.0977] As far as I'm aware it was not, though ljharb might know otherwise [09:53:14.0973] > <@tkopp:matrix.org> I thought that `try` in FP is exactly for lifting the result of an operation (sync or async) into a monad (Either) and thereby dealing with exceptions (Left(error), Right(value) or in JS terms reject(error), resolve(value)). > > I was under the impression that Promise.try was created with FP as a reference. nope, definitely nothing to do with FP at all and 100% to do with try/catch 2026-06-06 [20:47:48.0042] Michael Ficarra: in Iterator.prototype.flatMap https://tc39.es/ecma262/multipage/control-abstraction-objects.html#sec-iterator.prototype.flatmap step 6.b.viii.4.b.ii: IfAbruptCloseIterator(backupCompletion, iterated). afaict it is impossible for backupCompletion not to be abrupt here? previous step produces it as a result of IteratorClose(innerIterator, completion), and IteratorClose can only result in a non-abrupt completion if passed a non-abrupt completion to begin with [20:48:46.0203] I reviewed that PR in https://github.com/tc39/proposal-iterator-helpers/pull/195 but missed this I guess 2026-06-08 [22:19:01.0132] today I needed a `Set.prototype.iteratorFrom` method, which I am pretty sure most implementations could do efficiently and which definitely cannot be done efficiently in userland. (that is: you give it an element in the Set, it gives you an iterator for that Set except advanced to point to that element.) thoughts? too obscure? [23:30:30.0362] > <@bakkot:matrix.org> today I needed a `Set.prototype.iteratorFrom` method, which I am pretty sure most implementations could do efficiently and which definitely cannot be done efficiently in userland. > > (that is: you give it an element in the Set, it gives you an iterator for that Set except advanced to point to that element.) > > thoughts? too obscure? There recently was a related request on discourse that I had a hard time finding the use case justified. [23:31:44.0817] But different enough I suppose. That request was about indexed access. [01:10:23.0154] https://es.discourse.group/t/map-and-set-getters-to-give-a-way-to-get-an-item-at-an-order/2541/33 [06:32:52.0636] That one also isn't actually implementable efficiently [06:32:59.0714] If it were I'd be all for it [08:15:04.0704] would anyone be upset if we declare **merged** tests to be a stage 3 entrance criteria? I understand it's not great from a champion perspective if they've done the tests, but from an implementer perspective i don't consider an unreviewed test262 PR sufficient. not everyone uses a vendored copy of test262 that supports pulling in unmerged tooling and in particular things like test262.fyi won't be able to show implementation support if there are no tests on main [08:15:25.0895] currently affects several stage 3 iterator proposals [08:15:49.0222] * would anyone be upset if we declare **merged** tests to be a stage 3 entrance criteria? I understand it's not great from a champion perspective if they've done the tests, but from an implementer perspective i don't consider an unreviewed test262 PR sufficient. not everyone uses a vendored copy of test262 that supports pulling in unmerged tests and in particular things like test262.fyi won't be able to show implementation support if there are no tests on main [08:40:35.0692] I would prefer that we say that test262 tests can be merged as long as they have been reviewed by at least one delegate [08:41:34.0359] I am happy to review some test262 tests so that proposals can advance (and have done so for the iterator proposals), but that only matters if they actually can advance given my review [09:05:26.0593] @linusgroh:matrix.org I would only support that if we lowered the bar for merging to test262, as @bakkot suggests [09:06:44.0216] I am not willing to grant the test262 maintainer group the ability to (with good or ill intent) indefinitely hold up any proposal [09:07:55.0278] IMO the purpose of that group should be maintaining the harness and keeping the repo orderly, not reviewing test PRs for correctness or completion [09:08:04.0739] reviewing test PRs is our shared responsibility [09:08:42.0633] * IMO the purpose of that group should be maintaining the harness and keeping the repo orderly, not reviewing test PRs for correctness or completeness [09:08:51.0106] * IMO the purpose of that group should be maintaining the harness and keeping the repo orderly, not reviewing test PRs for correctness or exhaustiveness [09:56:28.0854] FWIW the process doc already says: > During Stage 2.7, Test262 tests should be authored and submitted via pull request. Once it has been appropriately reviewed, it should be merged to aid implementors in providing the feedback expected during this stage. so I'd wouldn't say it's unreasonable for someone to block a proposal over unmerged tests today 🤷 [09:56:34.0289] but i support whatever process change improves the situation for implementers