| 16:59 | <ljharb> | is there any way we can get the captioner to hit enter less often? |
| 17:00 | <littledan> | we should ask them to do so |
| 17:00 | <littledan> | others in their team know how to do it |
| 17:00 | <littledan> | just interrupt and tell them, please copy the settings from your colleagues who do this right |
| 17:00 | <littledan> | as well as any other quality issues, we should just note it to them |
| 17:06 | <nicolo-ribaudo> | Fyi, Webex has a "zoom in button" which works quite well |
| 17:10 | <kriskowal> | I got a lead on a paper that purportedly discusses context joins but I’ve not yet found the bit I remember about deferring “baggage” merge to the point of consumption. Still, it’s pertinent to async context motivating use cases https://cs.brown.edu/~jcmace/mace_thesis.pdf |
| 17:12 | <kriskowal> | I got this from the proverbial horse’s mouth. I reached out to Yuri Shkuro in the Cloud Native Foundation’s Slack. |
| 17:14 | <kriskowal> | In any case, I think reverse context propagation is probably a non-starter just because it implies that parent contexts will have to at least weakly retain child contexts, or something that has a similar retention graph, regardless of any as-yet-unsought implications for security. |
| 17:21 | <shu> | Chris de Almeida: seems like there's a lot of free time this meeting. can i request a 30min continuation of Atomics.pause discussion if it doesn't spill to day 4? |
| 17:27 | <Chris de Almeida> | shu: do you want 30 mins today before lunch? |
| 17:28 | <shu> | i'd prefer to not bump anyone else already lined up and do it at the end |
| 17:28 | <shu> | but will defer to chairs' judgment for the best schedule |
| 17:28 | <Chris de Almeida> | it's not quite bumping folks |
| 17:28 | <Chris de Almeida> | we got back time from the last 2 topics going quickly |
| 17:28 | <shu> | i'd still prefer we try to move other already scheduled topics up first |
| 17:28 | <shu> | if no other takers i'll take it |
| 17:28 | <Chris de Almeida> | ok |
| 17:40 | <Justin Ridgewell> | Can we no longer reply to the active TCQ topic? |
| 17:41 | <Chris de Almeida> | you can |
| 17:41 | <ryzokuken> | you can't |
| 17:41 | <ryzokuken> | because its a clarifying question itself |
| 17:41 | <Chris de Almeida> | we are currently on a clarifying question item |
| 17:42 | <Chris de Almeida> | what? |
| 17:42 | <ryzokuken> | yeah it's not a full topic |
| 17:42 | <Chris de Almeida> | yes, you can't reply to a clarifying question, once we advance past clarifying questions, the button you want will return |
| 17:43 | <Chris de Almeida> | if you have a reply to this topic, use clarifying question I guess? |
| 17:43 | <ljharb> | (that's what i did) |
| 17:45 | <bakkot> | tcq feature request: convert the current item to a real topic |
| 17:45 | <bakkot> | or just allow replying to clarifying questions, I guess |
| 17:49 | <Aki> | Frank isn't on Matrix, right? |
| 17:50 | <ryzokuken> | apparently not |
| 17:50 | <Aki> | The notes lack a summary/conclusion for his topic, would someone please volunteer to either get him to write it (if you have a way of being in contact) or writing it up? |
| 17:51 | <Chris de Almeida> | ah, we forgot to ask I think |
| 17:52 | <Chris de Almeida> | and the earlier topic as well |
| 17:53 | <Aki> | yeah i already messaged Michael to take a look after this topic |
| 17:54 | <ryzokuken> | thanks for the reminder I'll ping Frank elsewhere |
| 17:54 | <Aki> | hat tip to saminahusain for reminding me. it's like an og phone tree ^_^ |
| 17:54 | <Aki> | (i bet half of you are too young to remember phone trees. i'll :redirect: to tdz) |
| 18:01 | <saminahusain> | 👍️ |
| 18:14 | <Aki> | Don't forget summary/conclusions! |
| 18:18 | <littledan> | peetk: would you be up for doing the proposal scrub? |
| 18:18 | <peetk> | sure |
| 18:19 | <rbuckton> | would like to point out that I will not be available for the rest of TC39 |
| 18:20 | <rbuckton> | I would have been available on Day 4, but will not be available after the lunch break today or the whole of tomorrow. |
| 18:20 | <littledan> | if we could do the proposal scrub some time today, that'd be really great, especially if we'll have tomorrow afternoon to cover other topics |
| 18:22 | <rbuckton> | So if we are not getting to the proposal scrub while I am present, I would ask that we postpone any decisions on proposals I am championing that are at stage 2. At the very least, any proposal at stage 2 that I am currently championing should be considered active, if lower on my current set of priorities. |
| 18:23 | <kriskowal> | https://en.wikipedia.org/wiki/Head-of-line_blocking |
| 18:26 | <Ashley Claymore> | So if we are not getting to the proposal scrub while I am present, I would ask that we postpone any decisions on proposals I am championing that are at stage 2. At the very least, any proposal at stage 2 that I am currently championing should be considered active, if lower on my current set of priorities. |
| 18:27 | <littledan> | yeah the scrub is not about making decisions, just bringing topics up to try to stimulate future discussion. |
| 18:27 | <littledan> | Any proposal to withdraw would have to be a separate agenda item |
| 18:31 | <littledan> | shu: I don't understand this characterization (which you've made before) about how TC39 just ships stuff and then sees what happens. This is what the stage process, and the various pre-Stage 3 polyfills and transpiler implementations (and sometimes engine implementations), are generally for. I think this has been working well. If you have concerns about this flow of prototyping and feedback, let's have some kind of discussion on it. |
| 18:32 | <littledan> | (I don't want to get this discussion into too much of a tangent though) |
| 18:32 | <littledan> | we made certain mistakes in the past but I feel like we can learn from those within our current process and improve |
| 18:32 | <shu> | it is not my experience that we get any signal from pre-stage 3 polyfills that affects design...? |
| 18:33 | <shu> | we don't really have a real incubation process |
| 18:33 | <shu> | i don't see how the staging process is one |
| 18:33 | <bakkot> | yeah we definitely don't actually get much feedback prior to engines |
| 18:33 | <bakkot> | emperically |
| 18:33 | <bakkot> | it would be nice if we did but it's hard to do |
| 18:35 | <littledan> | what kind of feedback should we be collecting that we're not? |
| 18:35 | <bakkot> | a bunch of people using the API and telling us how it went |
| 18:35 | <littledan> | are there other examples of more successful bodies who do manage to do this? |
| 18:35 | <shu> | WICG? |
| 18:36 | <bakkot> | java ships things as experimental for a very long time |
| 18:36 | <shu> | like, OTs exist for this reason |
| 18:36 | <kriskowal> | toSorted()!? |
| 18:36 | <shu> | though that's chrome-specific |
| 18:37 | <littledan> | many TC39 features don't really need OTs or shipping as experimental--we can encourage trials via polyfills and transpilers. I guess we haven't been good about making sure we collect feedback when those are out there? |
| 18:38 | <bakkot> | also C++ often just standardizes stuff from boost, which is a similar deal |
| 18:39 | <shu> | many TC39 features don't really need OTs or shipping as experimental--we can encourage trials via polyfills and transpilers. I guess we haven't been good about making sure we collect feedback when those are out there? |
| 18:39 | <shu> | we rely on the makeup of delegates to be a good proxy |
| 18:46 | <dminor> | Could someone please point me to the html integration issue/PR for Error.isError? |
| 18:46 | <littledan> | +1 to non-piercing |
| 18:46 | <bakkot> | template literal array objects are frozen so there's not really any reason to proxy them |
| 18:47 | <bakkot> | the proxy can't behave any differently from the underlying thing, except for === and weakmaps and so on |
| 18:47 | <littledan> | also C++ often just standardizes stuff from boost, which is a similar deal |
| 18:47 | <dminor> | Found it, https://github.com/whatwg/webidl/pull/1421 |
| 18:48 | <bakkot> | that's fair, I haven't been following them closely for the last decade or so |
| 18:48 | <bakkot> | it used to be the case that they'd lift things wholesale, I think |
| 18:49 | <littledan> | yeah a decade ago was sort of the heyday of that, but then boost slowed down. it was related to the lack of movement in WG21 in the preceding decade, also. |
| 18:50 | <waldemar> | There are a bunch of places where one can find exact, correctly-rounded implementations of the trig and exponential functions on doubles. Here's one: https://core-math.gitlabpages.inria.fr/ |
| 18:50 | <littledan> | I'm curious if there's a good example of a library-type web API where we can look back on their pre-shipping "real world" feedback and say it's a good model to follow. That could help us. |
| 18:52 | <Michael Ficarra> | There are a bunch of places where one can find exact, correctly-rounded implementations of the trig and exponential functions on doubles. Here's one: https://core-math.gitlabpages.inria.fr/ |
| 20:00 | <Ben> | microphone problems again, I'll volunteer though |
| 20:01 | <saminahusain> | TC39 Hats available |
| 20:02 | <Ashley Claymore> | I can do the first 30 mins |
| 20:02 | <Ashley Claymore> | but my topic is up after that |
| 20:14 | <Chris de Almeida> | http://ptomato.name/talks/tc39-2024-07 |
| 20:14 | <Chris de Almeida> | Temporal slides |
| 20:26 | <nicolo-ribaudo> | Thanks ptomato for teaching us all those trivia about weird date edge cases btw, they are good conversation topics :) |
| 20:28 | <snek> | classic icebreaker: what's your favorite calendar edge case |
| 20:42 | <bakkot> | previous discussion of the current topic is in https://github.com/tc39/notes/blob/main/meetings/2024-02/feb-6.md#joint-iteration-for-stage-2 |
| 20:53 | <Chris de Almeida> | I could've sworn we talked about TZ canonicalization more recently than that? |
| 20:54 | <Michael Ficarra> | @peetk proposals repo doesn't have good last-presented dates, use https://github.com/tc39/dataset for that next time |
| 20:57 | <ptomato> | 2023-07 https://github.com/tc39/notes/blob/main/meetings/2023-07/july-12.md#time-zone-canonicalization-for-stage-3 |
| 20:59 | <ljharb> | proposals list is updated |
| 21:02 | <Michael Ficarra> | I think there's a big disconnect between how excited the community is for the pipeline operator and how excited the committee is |
| 21:03 | <ptomato> | I personally don't think the pipeline operator is worth it but that's a weakly held opinion and I'm not speaking on behalf of Igalia |
| 21:03 | <Michael Ficarra> | @ptomato same |
| 21:04 | <bakkot> | fwiw pipeline is also the proposal that I hear the most negative sentiment about, in its current iteration |
| 21:05 | <Richard Gibson> | I would use pipeline all the time in terminals and dev tools, and rarely in committed code |
| 21:06 | <Justin Ridgewell> | Is GoDaddy still a member? |
| 21:06 | <ljharb> | the community people who don't like pipeline are generally the ones who want F#, and they're a very vocal and small group |
| 21:06 | <Aki> | does anyone remember off the top of their head why upsert got renamed to emplace or do i have to go search some notes |
| 21:07 | <ptomato> | the community people who don't like pipeline are generally the ones who want F#, and they're a very vocal and small group |
| 21:07 | <ljharb> | i don't recall; "upsert" is a pretty typical term in databases |
| 21:07 | <Justin Ridgewell> | I remember somthing about typo being upskirt… |
| 21:07 | <ljharb> | i'm not sure anyone outside of that flamewar has voiced any opinion other than "i want pipeline" and "don't pick something ugly" (referring to the surface syntax) |
| 21:07 | <Michael Ficarra> | yeah everyone knows this function as upsert |
| 21:07 | <ljharb> | that would be bad but that seems like a reach (eg an unlikely typo) |
| 21:07 | <Aki> | oh god |
| 21:08 | <Richard Gibson> | https://github.com/tc39/proposal-upsert?tab=readme-ov-file#why-are-we-calling-this-emplace
|
| 21:09 | <shu> | "ordering was problematic"? |
| 21:09 | <Mikhail Barash> | A clarification regarding emplace: indeed, a group of students from University of Bergen will be implementing this in several engines. |
| 21:09 | <Aki> | "unique"? |
| 21:09 | <Richard Gibson> | I believe that's referring to ordering of the method's parameters |
| 21:09 | <Michael Ficarra> | A clarification regarding |
| 21:10 | <Michael Ficarra> | "unique"? |
| 21:10 | <shu> | I believe that's referring to ordering of the method's parameters |
| 21:11 | <Richard Gibson> | how is that related to what the method is named? |
| 21:11 | <Aki> | i feel like we decided on the name for upsert at salesforce in december 2019 but i may be getting my topics mixed up |
| 21:11 | <shu> | i have no recollection of its being renamed emplace |
| 21:13 | <ljharb> | https://github.com/tc39/proposal-upsert/commit/62c046861480fabb877e78fe4a0403fa5e7f5d3c was in 2020 |
| 21:14 | <Mikhail Barash> | The goal of the course is for the students to learn how the engines work. We selected this proposal as it seemed relatively straightforward to implement. In principle, we'd be interested in trying to bring the proposal to stage 2.7. |
| 21:14 | <bakkot> | I honestly have grown to like java's compute/computeIfAbsent/computeIfPresent |
| 21:18 | <eemeli> | The upsert/emplace name change happened here: https://github.com/tc39/notes/blob/main/meetings/2020-07/july-22.md#upsert-now-renamed-emplace-updates--for-stage-3 |
| 21:19 | <littledan> | yeah the summary for this is really per-proposal and can only be written after. Thanks for writing that, peetk |
| 21:19 | <littledan> | I think this scrub was valuable, hopefully for unblocking things like collection normalization, destructuring private fields, and especially String.dedent |
| 21:20 | <ljharb> | stage 3 could probably use a scrub too tbh |
| 21:20 | <littledan> | we did that recently though. I think it might be time for Stage 1 next time |
| 21:21 | <littledan> | The feedback for pipeline was also IMO, for my coworker who wants to take this up |
| 21:21 | <ljharb> | oh, i didn't know we did a stage 3 scrub - must have been one of the europe meetings while i was remote |
| 21:21 | <littledan> | yeah we did it in Helsinki |
| 21:21 | <ljharb> | what was up with "legacy regex features"? |
| 21:21 | <littledan> | we had a pretty long discussion about that actually... |
| 21:22 | <ljharb> | i suppose i could dig into the notes if a tldr isn't forthcoming :-) |
| 21:22 | <littledan> | I wish I had a tldr; it was a bit ambiguous |
| 21:22 | <littledan> | I suggested putting a deadline on some movement happening. This didn't get consensus. |
| 21:22 | <littledan> | some browsers expressed that they would be happy to accept a PR, but that it was relatively low priority for them |
| 21:23 | <littledan> | JSC expressed that they weren't sure about this proposal, as it'd add extra legacy features that they don't have |
| 21:24 | <littledan> | I argued, we should really get moving on this since it's important for all of the JS engines that do Annex B to agree with each other (and we've been able to manage this for JS and the web in a bunch of other cases historically--ugly legacy doesn't mean it's not possible to unify) |
| 21:30 | <shu> | i do not understand what is being proposed |
| 21:30 | <littledan> | this is navigator.locales right? |
| 21:33 | <ptomato> | Intl.supportedValuesOf('locale')? |
| 21:44 | <shu> | how is revealing locales different from a fingerprinting perspective vs revealing languages? |
| 21:44 | <shu> | like navigator.languages |
| 21:45 | <ryzokuken> | we're not even restricting enumerating the locales |
| 21:46 | <ryzokuken> | we just want to restrict that to a deterministic set for a given browser |
| 21:46 | <ryzokuken> | instead of something more dynamic |
| 21:46 | <Justin Ridgewell> | How do you use a locale if it’s installed? |
| 21:46 | <ryzokuken> | how so? in terms of API it only affects the enumeration API from Locale info |
| 21:47 | <danielrosenwasser> | Heads up TC39 friends: I'll be providing an update from TypeScript on some potential upcoming work on our side. It's not a proposal for JavaScript/ECMAScript and doesn't need consensus - we just want to sync up with the committee and collect relevant feedback. If we all feel like it's useful, we can do more updates like this in the future. |
| 21:49 | <ryzokuken> | How do you use a locale if it’s installed? |
| 21:50 | <Justin Ridgewell> | I understand, but how do you use a locale when it’s one of the default locales? |
| 21:51 | <Justin Ridgewell> | Like, do we need to redesign the entire make getting locale usage async? |
| 21:51 | <Justin Ridgewell> | Should you need a Locale instance to do anything with translating? |
| 21:52 | <ryzokuken> | they're optional at the moment, like you can use a constant locale id string instead |
| 21:53 | <Justin Ridgewell> | Do you have a code sample of how it’s used? |
| 21:53 | <ryzokuken> | sure, sec |
| 21:56 | <ryzokuken> | |
| 21:56 | <eemeli> | Many moons ago I wrote this for how locale loading could work: https://github.com/eemeli/proposal-intl-loadlocales With that, once the promise resolves, the sync |
| 21:57 | <Justin Ridgewell> | So it’s immediately obvious whether the locale is installed or not. |
| 21:57 | <ryzokuken> | yes |
| 21:57 | <Justin Ridgewell> | The API itself means it’ll never be possible to async install a locale without revealing that it’s not currently installed. |
| 21:57 | <Justin Ridgewell> | So what’s the point of this presentation? |
| 21:58 | <ryzokuken> | Mozilla's position on Intl enumeration was that they're fine with an Intl API enumerating locale information as long as hosts don't dynamically change the set of installed locales |
| 21:58 | <ryzokuken> | my understanding is that the current PR aims to build on that original position |
| 21:59 | <Justin Ridgewell> | But it’s obvious whether it’s installed because you can just use the API? |
| 21:59 | <littledan> | Mozilla's position on Intl enumeration was that they're fine with an Intl API enumerating locale information as long as hosts don't dynamically change the set of installed locales |
| 21:59 | <littledan> | But it’s obvious whether it’s installed because you can just use the API? |
| 21:59 | <littledan> | but it already wasn't hard at all |
| 21:59 | <ryzokuken> | it is currently met but there's nothing normative in the spec avoiding it from not being met in the future |
| 21:59 | <Chris de Almeida> | YAGNI invocation? |
| 21:59 | <ryzokuken> | was my understanding of the motivation |
| 21:59 | <Justin Ridgewell> | The API itself makes it impossible to meet. |
| 22:00 | <Justin Ridgewell> | It’s a sync API. |
| 22:00 | <ryzokuken> | so we're basically just avoiding further/easier fingerprinting |
| 22:00 | <Justin Ridgewell> | hourCycle either returns the correct result sync, or it doesn’t, and that can’t change without changing all the APIs |
| 22:01 | <Aki> | I was trying to get on to the queue but was having brain and technical problems |
| 22:01 | <Aki> | the financial motivation will p much always exist to track end users more |
| 22:01 | <Aki> | so i think we should add it |