| 12:59 | <styfle> | Are the meetings recording audio or video? Or is it just text transcripts? |
| 13:00 | <nicolo-ribaudo> | Just transcripts |
| 14:23 | <kriskowal> | Yes, and my understanding is that individual presenters are welcome to ask the committee for permission to record their own presentations, but not the conversation about their presentation, and publish in their own venues. This happens rarely enough that I don’t feel bad reminding seasoned delegates. :-) |
| 16:53 | <ryzokuken> | @room we're starting in 7 mins! |
| 17:09 | <Michael Ficarra> | Rich Hickey created Clojure, Rich Harris created Svelte |
| 17:19 | <bakkot> | what if we just had an explicit "IsProxy"... |
| 17:20 | <bakkot> | I would also like to be able to tell if touching a random object in any way at all is going to have side effects |
| 17:20 | <bakkot> | I think that's a capability I should be allowed to have |
| 17:21 | <Michael Ficarra> | @bakkot you'll still have accessors to worry about |
| 17:21 | <bakkot> | I can tell if a non-proxy has an accessor |
| 17:23 | <Mathieu Hofman> | Where did nicolo-ribaudo 's AsyncContext question go ?? |
| 17:24 | <Michael Ficarra> | people can delete their own TCQ items |
| 17:24 | <Mathieu Hofman> | I was interested in that question ;) |
| 17:25 | <Michael Ficarra> | you can always add it yourself |
| 17:25 | <nicolo-ribaudo> | I was going to say "Svelte will switch to AsyncContext rather than synchronously reading .then", but probably svelte moving away from it in a few years means that we'll never be able to assume everybody updated anyway |
| 17:27 | <ljharb> | you know i'm gonna love a Promise.isPromise |
| 17:27 | <Chris de Almeida> | no lies detected |
| 17:27 | <Justin Ridgewell> | styfle: I no longer have access to the private Vercel repos. Can you check if the AsyncLocalStroage polyfill I implemented for edge runtime usess a .then accessor? |
| 17:32 | <bakkot> | Mathieu Hofman: Symbol.unthenable is another lookup |
| 17:32 | <bakkot> | that's the opposite of the point |
| 17:32 | <nicolo-ribaudo> | 4 hours on the last day all for this topic! React with 🫠 to vote in favour of this |
| 17:32 | <Mathieu Hofman> | Right it'd require a non proxy check, and these to be non-configurable and non-writable, which is kinda meh |
| 17:33 | <bakkot> | just seems way worse than having an internal slot |
| 17:33 | <Mathieu Hofman> | I'd love a temp check on Promise.isPromise see if it'd be viable to bring as a proposal |
| 17:34 | <naugtur> | Would it also have Promise.isThenable ? |
| 17:34 | <bakkot> | you can sort of build it already by adding a .constructor getter to the object and then awaiting it |
| 17:34 | <bakkot> | so... would be nice to have something better than that |
| 17:34 | <bakkot> | except no one is doing that afaict |
| 17:34 | <naugtur> | assert(!Promise.isThenable({})) would be a good first line of program code |
| 17:36 | <Mathieu Hofman> | To be clear I would use Promise.isPromise to build a safe userland Promise.safeResolve and Promise.withSafeResolvers that introduces an extra tick unless the objects is an unmodified native promise. |
| 17:37 | <Mathieu Hofman> | Why not assert(!Object.getOwnProperty(Object.prototype, 'then')) ? |
| 17:38 | <bakkot> | what if we changed the in operator to return false if there is a nonwritable-nonconfigurable undefined-valued data property |
| 17:39 | <mgaudet> | Whooooooops |
| 17:39 | <bakkot> | so that we could just make Object.prototype.then permanently undefined without breaking people doing 'then' in foo |
| 17:39 | <naugtur> | My idea was to be future-compatible with a situation when there's a change to then on prototypes being ignored when considering a thenable |
| 17:39 | <ljharb> | my immediate instinct is that would break a ton of things in subtle ways |
| 17:39 | <Mathieu Hofman> | The TCQ queue didn't advance for me |
| 17:39 | <bakkot> | I bet it would be fine, that situation doesn't come up much |
| 17:49 | <Chris de Almeida> | still? |
| 18:09 | <Mathieu Hofman> | bakkot: did I capture your suggestion correctly regarding stack accessor being a closure? https://github.com/tc39/proposal-error-capturestacktrace/issues/1#issuecomment-3133528880 |
| 18:10 | <bakkot> | yup |
| 18:22 | <rbuckton> | This is one of the reasons I pushed for static {} to be included in the same edition as private fields, so that they were more likely to be transpiled in the same step to avoid any intermediate static private fields. |
| 18:24 | <snek> | not that people can object to babel making changes... |
| 18:29 | <keith_miller> | I think TCQ is still on "Non-extensible Applies to Private status update" |
| 18:40 | <bakkot> | https://github.com/whatwg/webidl/issues/1487 |
| 18:48 | <ryzokuken> | sorry for the TCQ hiccups everyone, we're taking note of every bug and issue and will finally have the chance to get all the fixes in by the next meeting thanks to the volunteers working on the fork |
| 18:59 | <Aki> | Back on my notes reminder: also don't forget to go clean up your summaries and conclusions. If you spoke them, go in quick and make them into bulleted lists or otherwise clear and concise copy |
| 19:03 | <Aki> | As far as remembering to record your summaries and conclusions, I'll start reminding individual speakers (privately) tomorrow. |
| 19:58 | <Chris de Almeida> | we are restarting |
| 20:01 | <Andreu Botella> | I can take notes |
| 20:02 | <naugtur> | I could do the next 30 minutes, but then I'm off to sleep |
| 20:07 | <nicolo-ribaudo> | Idea: note taking duty falls on the delegates in the timezone of the meeting |
| 20:08 | <nicolo-ribaudo> | Love the slide telling me I gave feedback way too late, sorry Michael |
| 20:10 | <nicolo-ribaudo> | Steve Hicks I think your topic is better as a reply to mine |
| 20:10 | <nicolo-ribaudo> | Since it seems to be the same concern I had in the issue |
| 20:21 | <ljharb> | should we do a temp check on the two options? (2 methods vs param) |
| 20:23 | <Justin Ridgewell> | A required param would also suffice for this. |
| 20:24 | <ljharb> | true, but/and if the param is required then it forces it to be a string for ergonomics, and because options bags are supposed to be for optional options |
| 20:26 | <Justin Ridgewell> | Sorry, I'm (badly) trying to be an impartial moderator |
| 20:26 | <nicolo-ribaudo> | Moderators are entitled to opinions! :P |
| 20:28 | <bakkot> | waldemar: I really dislike the "with remainder" naming because it implies to me that it's like how chunks gives you a truncated final chunk even in the case that the input is longer than the chunk size (if it is not a multiple) |
| 20:29 | <ljharb> | why wouldn't we make the default "throw"? |
| 20:30 | <bakkot> | Michael Ficarra doesn't like throwing |
| 20:31 | <ljharb> | i love throwing |
| 20:31 | <nicolo-ribaudo> | I'd very much prefer to make it required than do "throw" |
| 20:32 | <nicolo-ribaudo> | Throw is an exception that depends on the shape of the input, rather than on how you are using the API |
| 20:33 | <sffc> | Can we do a TG5 study to help with this? Seems like something easy to write research questions for |
| 20:34 | <bakkot> | we have lots of exceptions that depend on the shape of the input? that's totally normal |
| 20:34 | <Andreu Botella> | same |
| 20:34 | <Chris de Almeida> | sorry... |
| 20:34 | <bakkot> | "this input is too small to handle the outputs you asked for" is a very normal case for throwing |
| 20:36 | <nicolo-ribaudo> | Well it doesn't mean that it's good -- it's for example common to forget that if you don't pass the second argument with .reduce it could throw, and you forget to test the empty array case |
| 20:36 | <bakkot> | well, sure, but that's still the right behavior for that method |
| 20:37 | <bakkot> | bad inputs are a fact about the world and throwing on them is usually the best option |
| 20:37 | <bakkot> | the problem isn't the API, it's the bad input |
| 20:37 | <Michael Ficarra> | here, you can hang it on your wall |
| 20:57 | <Michael Ficarra> | we literally just advanced "upsert" to Stage 3, I don't think we have much of an appetite for renaming proposals |
| 20:58 | <Michael Ficarra> | that's why it's important to name your proposals appropriately (focusing on the problem statement) from the beginning |
| 20:58 | <bakkot> | in fairness the problem statement here is also reduced from the original |
| 20:58 | <Aki> | wasn't upsert reduced as well? |
| 20:59 | <bakkot> | true |
| 21:16 | <Jesse> | FYI we essentially agreed to drop currency https://github.com/tc39/proposal-measure/pull/44 |
| 21:17 | <Jesse> | (so the slides are technically up-to-date but don't quite reflect current thinking among those working on these ideas) |
| 21:30 | <bakkot> | I am curious if anyone else shares my concern about this not being super well-motivated as a language feature |
| 21:32 | <sffc> | About internal slots: the Temporal proposal looks at slots in order to choose a formatting code path in Intl.DateTimeFormat: https://tc39.es/proposal-temporal/#sec-temporal-handledatetimevalue |
| 21:33 | <bakkot> | is that AO called on arguments, or just the receiver? |
| 21:33 | <bakkot> | I guess presumably arguments given it's DateTimeFormat |
| 21:33 | <sffc> | And it looks like it reads the inner [ISODate] slot to figure out what to actually render |
| 21:33 | <ljharb> | i think we can just presuppose that internal slots aren't accessed on arguments of prototype methods |
| 21:34 | <sffc> | This is in Intl.DateTimeFormat.prototype.format, when passing a Temporal instance |
| 21:34 | <ljharb> | but for a true slotted object, an implementation would presumably be able to have a fast path |
| 21:35 | <kriskowal> | I like the idea of having a precedent-setting example of the protocol needed by Intl, and also like having “big decimal”, such that “decimal” might strictly show up as a typed array view, as is consistent with uint64 being reified as bigint. |
| 21:35 | <sffc> | IIRC, the champions proposed this shape for Intl.DTF so that we could use fast paths and avoid calling user code |
| 21:36 | <bakkot> | the usual pattern in Temporal, which I assumed would extend to Intl.DTF, is to check for the slots but fall back to reading properties if the slots are not present https://tc39.es/proposal-temporal/#sec-temporal.plaindatetime.from |
| 21:36 | <kriskowal> | Thanks for noting that. It does suggest an impasse. |
| 21:37 | <kriskowal> | I’ll run this by Mark. |
| 21:39 | <TabAtkins> | We could have a built-in class and a same-shaped protocol, and fast-path the built-in one, yeah. |
| 21:40 | <kriskowal> | My intuition is that inspecting internal slots and falling back to properties would settle the issue for purposes of membrane transparency, but pending response from MarkM. |
| 21:41 | <bakkot> | it's technically not transparent in that you can take an instance of the built-in class and define own getters which make the observable properties different from the internal slots, and then a Proxy for that will not behave like the thing itself, but like... whatever |
| 21:42 | <kriskowal> | Aye. I’m still absorbing how far the goalpost of “practical” in “practical membrane transparency” can move. I suspect that this is practical. |
| 21:43 | <bakkot> | might be worth extending Intl.DTF to do the same thing, if practical |
| 21:44 | <Justin Ridgewell> | Could I use this to tell if I have a Proxy wrapped object? |
| 21:44 | <Justin Ridgewell> | Re: promise.then proposal suggestion about not impacting objects without a .then property |
| 21:44 | <nicolo-ribaudo> | No, it would look like a plain object with the same shape but no internal slot |
| 21:45 | <nicolo-ribaudo> | It would look like a polyfilled version |
| 21:45 | <Justin Ridgewell> | Yah, but I could set an accessor for the field and see if it's accessed? |
| 21:45 | <bakkot> | it would be accessed for both a proxy and a plain object |
| 21:45 | <bakkot> | this allows you to distinguish a Proxy for a Temporal object from a non-Proxy'd Temporal object |
| 21:46 | <bakkot> | it does not allow you to identify arbitrary Proxies |
| 21:46 | <bakkot> | and all the methods which look at the slot on their this also distinguish a Proxy for a Temporal object from a non-Proxy'd Temporal object |
| 21:46 | <bakkot> | so it's not a new capability |
| 21:47 | <Justin Ridgewell> | Wouldn't the method invoke on it's target? Usually this is a throw when invoking on a non-instance directly. |
| 21:47 | <nicolo-ribaudo> | Justin Ridgewell could you maybe convert Jordan and my topics as replies to the current topic? |
| 21:47 | <bakkot> | right, and "non-instance" here includes "proxy for an instance" |
| 21:48 | <Justin Ridgewell> | Done |
| 21:54 | <ljharb> | +1 to justin, sigfig shrinkage only |
| 21:55 | <ljharb> | oh hm, that's also a good point for currency from waldemar, i now hold contradictory beliefs |
| 21:56 | <Andreu Botella> | can we create a new Amount with additional significant digits? |
| 21:56 | <ljharb> | that seems reasonable regardless because it's explicit |
| 21:58 | <waldemar> | Is there any potential for future ambiguity where the same string can be both a unit and. currency? |
| 21:58 | <nicolo-ribaudo> | I think in unicode all units are lowercase, and we could say all currencies are uppercase |
| 22:04 | <Jesse> | that's right |
| 22:04 | <Jesse> | lots of discussion, please do file issues! |
| 22:04 | <Chris de Almeida> | https://github.com/tc39/proposal-measure/issues |
| 22:05 | <Chris de Almeida> | also note: #tc39-decimal:matrix.org |
| 22:05 | <Jesse> | currently Amount is agnostic about this; only in Intl.NumberFormat, configured to render an amount as currency or as a unit, would we throw |
| 22:05 | <mgaudet> | kWh? |
| 22:05 | <Jesse> | so e.g. new Amount(5, { unit: "eur" }) is fine from Amount's point of view, but Intl.NumberFormat would complain if you pretend that "eur" is a currency |
| 22:06 | <nicolo-ribaudo> | kWh? |
| 22:06 | <Jesse> | we're looking mainly at this for inspriation: https://github.com/unicode-org/cldr/blob/main/common/supplemental/units.xml |
| 22:06 | <mgaudet> | Ahh, I follow now |
| 22:07 | <Andreu Botella> | how does Unicode write GiB |
| 22:07 | <Jesse> | I think the question is settled by just removing the currency option? https://github.com/tc39/proposal-measure/pull/44 |
| 22:08 | <Jesse> | kilowatt-per-hour |
| 22:08 | <Jesse> | there's also compound units like kilowatt-hour |
| 22:09 | <eemeli> | In https://tc39.es/ecma402/#sec-currency-codes we have an existing dependency on ISO 4217, which states that currency codes are canonically uppercase. And we can (and should!) explicitly require upper-case currency codes in Amount. |
| 22:10 | <Jesse> | you can create an amount from e.g. a string, query the significant digits, and then use the with method to create a new amount with the same underlying mathematical value but with more significant digits |
| 22:11 | <Jesse> | (IIUC) |
| 22:14 | <Jesse> | I think nicolo-ribaudo suggested having an option for banning more significant digits than exist in the original value? |
| 22:15 | <nicolo-ribaudo> | Nope |
| 22:20 | <sffc> | On the ToIntlMV question: I did some archaeology for where it came from. It was discussed in the November 2022 and January 2023 TC39 meetings, in the following PR. It does not appear that I specifically asked waldemar to review the PR, which in hindsight would have been a good call. https://github.com/tc39/proposal-intl-numberformat-v3/pull/128#issuecomment-3134230756 |
| 22:38 | <Justin Ridgewell> | eemeli: Given the objection to Amounts proposal, do we still need the continuation for Trailing Zero's 2.7 discussion? |
| 22:39 | <Justin Ridgewell> | If we don't, then we could possibly fit all items into tomorrow's timeslots and wrap up on Day 3. |
| 22:40 | <eemeli> | Yes, I would still very much like a continuation for keep-trailing-zeros. As I understood it, during the Amount discussion we were able to identify that waldemar's blocking concern for it (in ToInltMathematicalValue) is beyond its scope, and ought to be addressed separately. So I'm interested in seeing if sffc has time to review the spec still during this meeting, so that it might advance to 2.7. |