TC39 Delegates on 2026-06-05

11:01	<Rob Palmer>	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.
14:03	<Tom Kopp>	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?
15:19	<bakkot>	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
15:22	<bakkot>	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.
15:26	<bakkot>	(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.)
15:42	<Aki>	Some of these summaries are somehow both terse and incredibly thorough, nice work everyone
15:47	<Michael Ficarra>	that's exactly what I was going for
15:48	<Chris de Almeida>	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
15:49	<Chris de Almeida>	I will try to take a stab at it shortly
16:35	<Rob Palmer>	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.
16:42	<Tom Kopp>	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.
16:51	<bakkot>	As far as I'm aware it was not, though ljharb might know otherwise
16:53	<ljharb>	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