| 14:56 | <mathiasbynens> | akirose: damn that's a nice ecma mug |
| 14:56 | <akirose> | my coffee is too hot to drink 😭 |
| 14:57 | <akirose> | but yes it sure is an Ecma mug |
| 14:57 | <akirose> | 🥳 |
| 14:58 | <akirose> | when i was in geneva last year a couple of us raided the swag closet |
| 14:58 | <akirose> | i got an umbrella too |
| 14:58 | <mathiasbynens> | there’s umbrellas?! |
| 14:59 | <ystartsev> | yep |
| 14:59 | <ystartsev> | we are all jealous |
| 15:00 | <mathiasbynens> | my inner rihanna must have one |
| 15:03 | <leobalter> | My computer had a forced update. I’ll join the meeting soon |
| 15:07 | <robpalme> | we are about to start String#replaceAll |
| 15:10 | <akirose> | that was in july last year, right? |
| 15:11 | <rkirsling> | 👏 |
| 15:11 | <jridgewell> | 👏 |
| 15:12 | <rickbutton> | congrats on the Stage 4 (pending editors)! |
| 15:13 | <shu> | i hope we all reviewed before this meeting, we try to anyway |
| 15:18 | <shu> | jridgewell: btw logical assignment will be stable by 85 *with* NamedEvaluation, was a trivial patch |
| 15:24 | <michaelficarra> | not everything we do has to set a precedent |
| 15:24 | <ljharb> | and yet, everything we do tends to |
| 15:25 | <michaelficarra> | this same topic came up yesterday with iterator helpers |
| 15:25 | <rricard> | @jridgewell, can you complete your question in notes? |
| 15:26 | <msaboff> | ystartsev: What does l,34 mean in the notes doc? |
| 15:27 | <ystartsev> | msaboff: i had the same question |
| 15:27 | <msaboff> | mathiasbynens: ^^ |
| 15:27 | <mathiasbynens> | mathiasbynens: me too, no idea who added it or what it means |
| 15:28 | <robpalme> | is Philip Chimento here? |
| 15:28 | <michaelficarra> | pipobscure, no? |
| 15:28 | <ryzokuken> | robpalme: can I take a message? |
| 15:28 | <marja_> | for more info, if you wonder how the AggregateError ctor order is observable, see the last test case here: https://chromium-review.googlesource.com/c/v8/v8/+/2139571/34/test/mjsunit/harmony/aggregate-error.js#1 (the last test, AggregateErrorCreation) |
| 15:29 | <robpalme> | enquiring if he is able to present Temporal now (after the current topic) |
| 15:29 | <ryzokuken> | robpalme: that's the plan 😇 |
| 15:29 | <ryzokuken> | Let me make sure he's in the meeting. |
| 15:30 | <robpalme> | specifically after Promise.any and *before* Unicode |
| 15:30 | <ryzokuken> | oh, right. I'll let you know in a sec. |
| 15:31 | <jridgewell> | shu: 🙌, thanks! |
| 15:31 | <ryzokuken> | robpalme: yes, they can do it 😄 |
| 15:32 | <robpalme> | thank you - we'll make it next and unicode will follow it (they are swapped) |
| 15:32 | <ryzokuken> | great, thanks for the heads up. |
| 15:33 | <rbuckton> | First convert to list, then call super, then assign errors? |
| 15:34 | <ljharb> | rbuckton: that would be fine with me, but the impl pushback was "prefer not to run any code before calling super" |
| 15:34 | <mathiasbynens> | the issue is https://github.com/tc39/proposal-promise-any/issues/14 |
| 15:38 | <rwaldron> | shu I'll add that AggregateError change to my schedule for tomorrow, should be super quick |
| 15:39 | <shu> | rwaldron: +1 awesome |
| 15:46 | <sffc> | What is the phone number for today's Teams call so I can call in for audio? (please DM it to me) |
| 15:48 | <bterlson> | sffc: dm sent |
| 15:48 | <mathiasbynens> | rwaldron: both changes? :) |
| 15:50 | <rwaldron> | mathiasbynens any test changes necessary to address https://docs.google.com/presentation/d/1juwk662pDATPCPqPxlE8M9rBGeA9zAp0_sJBoxu3eMc/edit#slide=id.g8753e62b92_0_16 |
| 15:50 | <rwaldron> | Unless you're referring to something else? |
| 15:50 | <rwaldron> | Looks like you an I are literally "on the same page" |
| 15:50 | <mathiasbynens> | rwaldron: yeah those are the two changes |
| 15:51 | <mathiasbynens> | rwaldron: just wanted to double-check you heard both discussions (since you said “change” not “changes”) |
| 15:51 | <mathiasbynens> | rwaldron: \o/ thanks! |
| 15:53 | <marja_> | rwaldron, afaics the order in which the aggregateerror ctor does stuff is not tested in test262, but it could be (see the link i posted above) |
| 15:53 | <marja_> | the tests in AggreagateErrors/errors must be rewritten, pretty much |
| 15:55 | <rwaldron> | marja_ thanks |
| 15:55 | <ljharb> | should be, imo |
| 15:56 | <shu> | how do you overflow bigints? |
| 15:56 | <shu> | oh |
| 15:57 | <michaelficarra> | a BigInt value in an internal slot? |
| 15:57 | <michaelficarra> | that makes no sense, they could just use mathematical values |
| 15:58 | <ljharb> | they may be thinking in terms of the polyfill |
| 15:58 | <ystartsev> | oh, dumb question - what would mathematical values mean here? |
| 15:58 | <ystartsev> | like, spec only values? |
| 15:58 | <mathiasbynens> | that |
| 15:59 | <bterlson> | I'm glad temporal continues the legacy of copying java by adopting their builder pattern |
| 15:59 | <rkirsling> | ^ this definitely reads as sarcasm but I'm not 100% sure it is? |
| 16:00 | <ryzokuken> | I mean, there's definitely enough factory functions in there. |
| 16:00 | <ryzokuken> | so guilty as charged, I guess |
| 16:01 | <TabAtkins> | +1 to defaulting to the iso calendar. bug potential isn't worth the heavy cost of specifying a calendar before every operation when 99%+ of all temporal usage will be in the iso calendar |
| 16:02 | <TabAtkins> | michaelficarra: The BigInt mattered because they were talking about the return value of `.valueOf()`, it's not just internal |
| 16:04 | <ryzokuken> | right, plus `Date` and friends can return a number. |
| 16:04 | <ryzokuken> | but then it'd make comparisons almost instantly fail once you mix with something with `Time`. |
| 16:05 | <michaelficarra> | TabAtkins: it's easy to make a BigInt from a mathematical value in valueOf |
| 16:05 | <TabAtkins> | michaelficarra: Yes, there was no problem with producing a BigInt. "Return a BigInt" was just one of the presented options (the other was throwing) |
| 16:06 | <michaelficarra> | TabAtkins: my comment was in reference to their statement that a BigInt was used in an internal slot, before we started talking about valueOf |
| 16:06 | <TabAtkins> | Ah kk |
| 16:07 | <michaelficarra> | see line 10 from this topic's notes if you want to read back |
| 16:16 | <ljharb> | sffc: isn't adding a day calendar-dependent if you're crossing a year or month boundary? |
| 16:18 | <TabAtkins> | ljharb: The day still advances the same for all calendars, no? The displayed value in a given calendar can care, but it's still a 24-hour advancement |
| 16:18 | <ljharb> | ah, i see |
| 16:18 | <ljharb> | what about over leap days? |
| 16:18 | <TabAtkins> | oh lol i was joking, i regret bringing up martian days |
| 16:18 | <ljharb> | leap days are 23 or 25 hours |
| 16:19 | <TabAtkins> | ljharb: Hm, that's a good point |
| 16:19 | <TabAtkins> | ljharb: worth bringing up |
| 16:19 | <TabAtkins> | I'll do so |
| 16:19 | <ljharb> | thanks |
| 16:19 | <Bakkot> | ... by "leap days" do you mean "days on which DST changes"? |
| 16:19 | <Bakkot> | Feb 29 is normally 24 hours |
| 16:19 | <ljharb> | oh duh sorry |
| 16:19 | <ljharb> | yes |
| 16:19 | <ljharb> | daylight savings days, not leap days. early morning brain hiccup |
| 16:44 | <robpalme> | is chris garrett here? |
| 16:48 | <mathiasbynens> | michaelficarra: adding the prose as non-normative would still addresses some of your concerns, right? |
| 16:49 | <ljharb> | mathiasbynens: that prose would be an improvement regardless |
| 16:53 | <mathiasbynens> | that’s what i thought, but when michaelficarra said he’d be “fine” with it i wasn’t sure anymore |
| 16:57 | <michaelficarra> | well it's a nice improvement, but it doesn't actually address the concerns I had |
| 16:57 | <ljharb> | same |
| 16:58 | <haxjs> | what's the next step of decorator? |
| 16:58 | <rbuckton> | As far as I can tell, nothing has changed yet with decorators, this primarily was providing information on the type of analysis that has been ongoing. |
| 17:00 | <marja_> | re longer lunch break, i appreciate the 1 hour break to be able to help out with kids; assuming it's similar for other folks who have whatever outside responsibilities |
| 17:12 | <rbuckton> | For whatever reason I can't get Edge or Chrome to pick the correct webcam to use on spatial.chat |
| 17:29 | <rickbutton> | rbuckton: same, using firefox prompted me for the webcam to use |
| 17:46 | <akirose> | took me this long just to cook my food |
| 17:46 | <akirose> | so i am ++ on hour lunches |
| 17:46 | <akirose> | also, it's bad, but i'll take that to TDZ |
| 17:51 | <sffc> | Is the schedule on hackmd.io still up to date? |
| 18:02 | <robpalme> | we are starting Function Impl Hiding now |
| 18:05 | <akirose> | sffc: close |
| 18:05 | <akirose> | i still need to catch up on what i missed before lunch |
| 18:06 | <sffc> | I assume Intl.NumberFormat v3 is moved up to 2pm local time, and Intl.DurationFormat up to 2:20pm local time? |
| 18:07 | <akirose> | assuming Function Implementation Hiding sticks to exactly 60 min, yeah? i think so? |
| 18:18 | <mmarchini> | fyi we'd be fine with being able to disable statically (for example, with a startup flag). I guess for this to be possible the feature would need to be optional? |
| 18:19 | <Bakkot> | you could just have a non-conforming implementation when the flag is on |
| 18:19 | <mmarchini> | right |
| 18:25 | <mmarchini> | when is the library call? I'd like to join too |
| 18:26 | <jridgewell> | I actually really like the "hide from stack traces" aspect |
| 18:26 | <ljharb> | i really like both :-( |
| 18:27 | <rkirsling> | ystartsev: really glad you said all that, I assumed that it was too much of a done deal to speak up at this point |
| 18:27 | <ljharb> | i'm very surprised that this is a common sentiment |
| 18:27 | <jridgewell> | Using Error helpers pollutes my error logging a ton |
| 18:27 | <ljharb> | stage 2 is supposed to mean "we are planning to put this in the language" |
| 18:27 | <ystartsev> | i need to look at how this was moved into stage 2 |
| 18:27 | <mmarchini> | what is the expectation when reporting errors on libraries with stack hiding? wouldn't it make harder for authors to debug issues? |
| 18:27 | <jridgewell> | We had to build a GitHub bot that stripped out the useless crap from error reports to focus on the actual code |
| 18:27 | <ljharb> | if multiple delegates/implementors had this opinion much prior to now, then it shouldn't have been stage 2 in the first place. |
| 18:28 | <ystartsev> | but i think we were under the impression that it would also have a performance improvement |
| 18:28 | <drousso> | ystartsev really well spoken and thought out :) |
| 18:28 | <ljharb> | ystartsev: is that something knowable prior to implementations and stage 3? |
| 18:28 | <ystartsev> | yes |
| 18:28 | <littledan> | here's the notes from that outreach call: https://docs.google.com/document/d/1vvL357Z6r9IYTItvNwBf0wRH-uT4J_bAFIqnbQb-13I/edit#bookmark=id.xscidqxjp5nf |
| 18:28 | <ystartsev> | we know that this will not have an improvement |
| 18:28 | <ljharb> | k |
| 18:28 | <littledan> | I believe that some of the use cases *were* blackboxing (but it's possible I misunderstood people) |
| 18:29 | <bradleymeck> | that question should have been a new topic i guess |
| 18:29 | <ystartsev> | yes that is how i understood it as well |
| 18:29 | <ljharb> | hiding source also would have prevented angular 1 from making "changing argument names" a breaking change. |
| 18:30 | <mmarchini> | I don't think it would? |
| 18:31 | <jridgewell> | That requires the angular user to be proactive, though |
| 18:31 | <littledan> | I think we discussed the Angular and lack-of-memory-improvement issues when proposing this for Stage 2, but IMO if Mozilla has serious concerns now, we shouldn't discard them at this point. |
| 18:31 | <ljharb> | jridgewell: true |
| 18:32 | <shu> | i take yulia's point, and am a "weak accept" on "hide source" in that it doesn't seem to hurt, but i have serious concerns about "sensitive" |
| 18:34 | <ljharb> | shu: i'm a strong +1 on hide source and also have concerns about "sensitive", fwiw |
| 18:34 | <littledan> | Note, there's a separate tools call, but we haven't discussed function implementation hiding as far as I can tell in the notes https://docs.google.com/document/d/1RlnAnMa4QzQUK_tNOHdWfnske2X9KZ_e90VBG-DWqUo/edit |
| 18:35 | <ystartsev> | i am really sorry michaelficarra. let's keep talking about it and i will join thosee other calls |
| 18:35 | <michaelficarra> | ystartsev: I understand it's not personal |
| 18:37 | howdoi | this is what I really like about this committee, maturity and mutual respect! 🙏 |
| 18:37 | <shu> | i am not understanding leo's point |
| 18:38 | <rickbutton> | blocking the proposal overall vs blocking the stage advancement request? |
| 18:38 | <rkirsling> | rickbutton: the latter |
| 18:38 | <rkirsling> | I don't think the former is actually a thing |
| 18:39 | <rickbutton> | right, I believe LBR's comment was to specify specifically the latter |
| 18:39 | <rickbutton> | unless I misunderstood |
| 18:41 | <leobalter> | shu: my purpose was disambiguation in the notes. As I said, my topic was a meta discussion on the wording we use. It was easily fixed as we all had the context fresh |
| 18:41 | <michaelficarra> | for the people questioning the security implications of stack inspection, please review my slides here: https://docs.google.com/presentation/d/15IWa2HM4sYUWmN_orRGFZ4H1D0AsZO4IcNliY68FwBE/edit |
| 18:41 | <robpalme> | this is Intl.NumberRange for Stage-2 |
| 18:42 | <leobalter> | robpalme: yes, but Intl.NumberFormat **V3** for Stage 2 |
| 18:43 | <ystartsev> | michaelficarra: our security stance is based on the situation with spectre, anything that is presented as a security feature without taking into consideration spectre is considered to... basically not fulfill the security requirement. I know you have a different stance here and I respect that. From the browser perspective I don't think this will change any time soon |
| 18:43 | <robpalme> | good clarification leo |
| 18:44 | <shu> | leobalter: thanks |
| 18:45 | <shu> | michaelficarra: chrome basically agrees with that view re: "security" in context of JS |
| 18:45 | <michaelficarra> | because JavaScript can't be made secure on systems affected by spectre, it can't be be made secure on any systems? that seems backwards to me |
| 18:46 | <shu> | preventing info leaks via a side channel that JS execution itself attempts to lock down is not that compelling, in that we aren't in a position to dictate to all present and future web APIs that they must respect this |
| 18:46 | <shu> | plus, timing is the primary side channel still |
| 18:46 | <shu> | michaelficarra: i don't think anyone claimed something that general |
| 18:47 | <shu> | but favoring systems that are not affected by spectre is a theoretical concern from my POV |
| 18:47 | <shu> | s/favoring/securing |
| 18:48 | <ystartsev> | It comes down to whether the feature is worth implementing. Security would not be a benefit here, and could potentially harm users and developers alike on the web due to false assumptions |
| 18:48 | <littledan> | I continue to be sad about the loss of a scale option. It'd be really useful! |
| 18:48 | <ystartsev> | it might benefit the few systems that are not exposed to spectre, but those are few and do not have as significant an impact on users as something the scale of the web |
| 18:49 | <ystartsev> | since this has this double edge, it would be better not to introduce it |
| 18:50 | <littledan> | My understanding from the framework notes was that people sort of wanted this for blackboxing... then, it sounded like omitting the stack frames from reflection APIs was more of a minus than a plus |
| 18:50 | <littledan> | maybe I misunderstood; michaelficarra could clarify |
| 18:50 | <michaelficarra> | so because of spectre, we've given up on allowing untrusted code to execute in the same realm following trusted code? how are websites supposed to integrate third party modules? |
| 18:51 | <michaelficarra> | I am much more surprised by this backpedaling on the security goal than I am the rejection of "hide source" |
| 18:51 | <ystartsev> | the security model that the web is following now is around process isolation and same origin sources (which, i am sure you know, but in case anyone wasn't aware) |
| 18:52 | <ystartsev> | so, third party modules are seen as the responsibility of the site that runs them |
| 18:52 | <shu> | michaelficarra: because of spectre, features that enable "safer" execution same-process non-isolated JS code shouldn't be advertised as having "security benefits" |
| 18:52 | <ystartsev> | ^ exactly |
| 18:53 | <ystartsev> | This isn't a backpedaling, its been an established position of browsers for some time now |
| 18:53 | <michaelficarra> | that's quite the renouncement of SES, then |
| 18:53 | <shu> | i am surprised you are surprised by my opinion on SES |
| 18:53 | <michaelficarra> | ystartsev: I see it as backpedaling because we acknowledged the problem when we moved my initial proposal to stage 1 |
| 18:53 | <ystartsev> | SES has a much higher bar now, yes. |
| 18:54 | <Bakkot> | I think SES attempts to limit side channels like timing, fwiw |
| 18:55 | <chicoxyzzy> | can invited experts be reviewers? |
| 18:56 | <ystartsev> | It might have been a mistake but i thought blocking something from stage 1 could only be for very specific things that had been discussed before? |
| 18:56 | <michaelficarra> | chicoxyzzy: I don't see why not |
| 18:56 | <ljharb> | chicoxyzzy: yes afaik |
| 18:56 | <ljharb> | ystartsev: blocking stage 1 means you don't think it's worth committee time to keep discussing it |
| 18:56 | <chicoxyzzy> | I'd like to be a reviewer if possible |
| 18:56 | <ljharb> | (and really this isn't "blocking", it's "not agreeing to advancement", regardless of how we phrase it) |
| 18:57 | <michaelficarra> | ystartsev: stage 1 acknowledges the problem, stage 2 agrees on a general solution, stage 3 solidifies a solution and asks for implementation |
| 18:57 | <ystartsev> | ok, i don't think that was the case for stage 1. its not like it was something that we didn't need to discuss and at the time there was more of an argument in favor of the proposal |
| 18:58 | <michaelficarra> | sure, I understand that our strategy for security on the web has shifted since the initial move to stage 1 |
| 18:58 | <michaelficarra> | still surprised me though |
| 18:58 | <ystartsev> | yes, it is unfortunate that this came as a surprise, and i am sorry for that |
| 18:59 | <ystartsev> | I do think it was time well spent at committee, and i think a lot of good work came out of this |
| 19:00 | <littledan> | chicoxyzzy: That'd be great! I think you should be able to be a reviewer. I am happy to answer any questions |
| 19:00 | <chicoxyzzy> | cool! thank you Daniel! |
| 19:02 | <ystartsev> | chatting with waldo, I might review shadowing him |
| 19:02 | <ystartsev> | cc sffc (so you might have a "joint mozillian review" there) |
| 19:03 | <sffc> | 😊 |
| 19:03 | <chicoxyzzy> | littledan: sffc: should I leave a comment somewhere? |
| 19:03 | <littledan> | maybe we should have a Stage 3 review issue, and we can collect the list of reviewers there |
| 19:04 | <littledan> | also ryzokuken and I might jointly do the Igalia review |
| 19:04 | <robpalme> | extra points for the prince of persia screenshot |
| 19:04 | <littledan> | so that's three reviews |
| 19:04 | <rkirsling> | robpalme: indeed |
| 19:05 | <michaelficarra> | I love the work being done in 402 |
| 19:05 | <sffc> | Thanks, everyone! Also note that we will also need reviewers for the Intl.DurationFormat proposal. I'll make sure everyone here is mentioned in the meeting notes. |
| 19:05 | <michaelficarra> | sffc: I will review DurationFormat |
| 19:05 | <ryzokuken> | (and I can't volunteer for that one 🙈) |
| 19:05 | <ryzokuken> | michaelficarra: thanks! |
| 19:07 | <rbuckton> | Was the spec text for Intl.DurationFormat up prior to the meeting? I recall looking yesterday and the spec link on the repo was empty |
| 19:08 | <sffc> | It's been in a PR |
| 19:08 | <rickbutton> | is there still another reviewer needed for Intl.DurationFormat? any requirements to be a reviewer? |
| 19:08 | <sffc> | A couple people have left feedback on the PR |
| 19:08 | <rbuckton> | Ah, I didn't see the PR, thanks! |
| 19:09 | <ystartsev> | rickbutton: last year i did a "shadow review" with domenic, it was really helpful |
| 19:09 | <ryzokuken> | rbuckton: yeah, it was a PR that was finalized and merged recently. Sorry for the delay. |
| 19:09 | <ystartsev> | i want to do it a couple more times just to find my feet |
| 19:09 | <ystartsev> | so, might be a nice way for you to ramp up also? |
| 19:09 | <rickbutton> | ystartsev: that sounds like a great idea |
| 19:10 | <ystartsev> | i think that might be a good way to expand our pool of reviewers, *looks at other members of the committee who are nervous about reviewing. * |
| 19:12 | <mpcsh> | ✋ |
| 19:12 | <rkirsling> | don't be afraid |
| 19:12 | <rkirsling> | it's fun |
| 19:12 | <ystartsev> | we should mark "good first reviews" and pair people up |
| 19:13 | <mpcsh> | I'm already doing this for Intl.Segmenter |
| 19:16 | <rkirsling> | segmenter would be fun |
| 19:19 | <ystartsev> | sffc: waldo and i are pairing on the review, i will add it to the notes |
| 19:21 | <rkirsling> | I'm happy to review as well but Ron beat me to it :P |
| 19:21 | <rkirsling> | lemme know whether a third is desired |
| 19:21 | <ryzokuken> | rkirsling: I don't see why not! 😄 |
| 19:21 | <ryzokuken> | I'll make a PR to the explainer adding you three. Thanks everyone! |
| 19:21 | <rkirsling> | 👍 |
| 19:24 | <robpalme> | this is Symbols as WeakMap keys for Stage 1 |
| 19:28 | <michaelficarra> | … and now we consider SES again? |
| 19:31 | <Bakkot> | petition to move on from this topic |
| 19:31 | <Bakkot> | (meaning the "box" thing, in particular) |
| 19:31 | <Bakkot> | guess we now are moving on |
| 19:31 | <rkirsling> | Bakkot: are you suggesting we think outside the box |
| 19:32 | <rkirsling> | also Fiddler is definitely not obscure |
| 19:32 | <akirose> | sffc: you sound like you're in a different room |
| 19:32 | <akirose> | and screaming into our room |
| 19:32 | <akirose> | is your device maybe using the wrong mic? |
| 19:33 | <howdoi> | BoxMaker reminds me of Monads. |
| 19:33 | <ljharb> | i think you mean "the container that must not be named" |
| 19:34 | <howdoi> | ^ nods |
| 19:34 | <Bakkot> | feeling a huge compulsion to argue about whether monads are containers |
| 19:35 | <ljharb> | oh noes |
| 19:35 | akirose | points at tdz |
| 19:35 | <akirose> | march, mister. |
| 19:35 | <rkirsling> | ^ |
| 19:35 | <ljharb> | um, call ended? |
| 19:35 | <howdoi> | no |
| 19:35 | <ljharb> | weird, must just be me |
| 19:35 | <ljharb> | maybe i accidentally pushed the button on my airpod |
| 19:35 | <howdoi> | ha, airpods |
| 19:36 | <howdoi> | Bakkot: would love to hear more! |
| 19:36 | <akirose> | due to the fact that Dan invited clarifying questions during his presentation, pls lmk if any of y'all feel strongly that your queue items should interrupt (or just use the "clarifying question" button) |
| 19:37 | <ljharb> | akirose: i added a topic because mine's "more of a clarifying comment" |
| 19:37 | akirose | nods |
| 19:39 | <sffc> | akirose: it says I'm muted on Teams |
| 19:39 | <jridgewell> | We muted you |
| 19:39 | <akirose> | yes it does. |
| 19:39 | <sffc> | Oops, sorry about that |
| 19:40 | <akirose> | all good |
| 19:40 | <sffc> | I got up to get a drink |
| 19:40 | <sffc> | and was talking in the other room |
| 19:40 | <Bakkot> | ljharb I'm not claiming this isn't motivated without records |
| 19:40 | <Bakkot> | just that it is not _worth it_ without records |
| 19:41 | <Bakkot> | I am aware of the motivation; you can read the existing discussion on github |
| 19:44 | <ljharb> | gotcha |
| 19:44 | <ljharb> | even without records, the template use case could still be a deeply frozen object, combined with a weakmap |
| 19:48 | <howdoi> | can anyone help me to find the definition for Temporal.Date.compare? [looking into the ployfill] |
| 19:49 | <sffc> | howdoi: the docs are https://github.com/tc39/proposal-temporal/blob/main/docs/date.md#temporaldatecompareone-temporaldate-two-temporaldate--number |
| 19:49 | <howdoi> | https://github.com/tc39/proposal-temporal/blob/61b88049ea2f8e099121ceb762b6465a8c161c10/polyfill/lib/date.mjs#L156 this? |
| 19:49 | <sffc> | Yeah, that looks like it |
| 19:49 | <howdoi> | cool, thanks |
| 19:50 | <ryzokuken> | howdoi: yep, that's it. |
| 19:50 | <ryzokuken> | but actually, also not. |
| 19:50 | <ryzokuken> | we have a PR |
| 19:50 | <ryzokuken> | for adding calendar logic. |
| 19:50 | <sffc> | I think the compare method doesn't delegate to the calendar |
| 19:50 | <ryzokuken> | oh |
| 19:50 | <sffc> | because we always compare in ISO space |
| 19:50 | <ryzokuken> | wait, yeah |
| 19:50 | <ryzokuken> | oof, my bad. you're right. |
| 19:51 | <sffc> | Relevant discussion: https://github.com/tc39/proposal-temporal/issues/625 |
| 19:51 | <rickbutton> | I am massively in favor of this, I literally ran into this problem last night |
| 19:52 | <brad4d> | what is the name for the tdz chat? couldn't find it in a quick look through how-we-work / how-to-attend-meetings |
| 19:52 | <rickbutton> | *compiling to wasm |
| 19:52 | <rickbutton> | brad4d: temporaldeadzone |
| 19:52 | <howdoi> | > Comparison and equality of dates with different calendars |
| 19:52 | <howdoi> | Exactly was my next question! |
| 19:53 | <littledan> | I'm vaguely +1 on this proposal |
| 19:54 | <howdoi> | would be useful, if the user could define a custom comparator? sffc ryzokuken |
| 19:54 | <ryzokuken> | well, you could always convert all dates to a single calendar and then compare... |
| 19:54 | <sffc> | The comparator is literally only the compare method. You have to call the method to use it |
| 19:55 | <ryzokuken> | we also considered allowing comparison if one of the calendars was ISO |
| 19:55 | <sffc> | For example, you have to pass Temporal.Date.prototype.compare into Array.prototype.sort |
| 19:55 | <sffc> | The comparator is not implicitly used anywhere |
| 19:56 | <sffc> | I think that's how it works at least |
| 20:39 | <rbuckton> | Temporal types now have a compare prototype member? Last I checked it was just a static compare |
| 20:40 | <ryzokuken> | rbuckton: just static compare indeed |
| 20:40 | <ryzokuken> | sffc: might've mistyped |
| 20:41 | <ryzokuken> | it's just `Temporal.Date.compare`, no prototype |
| 20:41 | <ryzokuken> | oooh, btw, dunno if you noticed, but we added a `.d.ts` 😇 |
| 20:43 | <rbuckton> | I am working on a draft for adding `@@equals`, `@@hash` (for use with Map/Set/user-defined equality comparisons), and `@@compareTo` for relational comparisons. Note that neither has anything to do with operator overloading and doesn't affect equality or relational operators. Its based on what I did here: https://esfx.js.org/esfx/api/equatable.html, and here: |
| 20:43 | <rbuckton> | https://esfx.js.org/esfx/api/collections-hashmap/hashmap.html#_esfx_collections_hashmap_HashMap_class |
| 20:44 | <ljharb> | rbuckton: like for a proposal? or for your library |
| 20:44 | <rbuckton> | A proposal. My library consists of things that I'd eventually like to propose |
| 20:44 | <ljharb> | rbuckton: you may want to wait for the "generic comparison" proposal on thursday |
| 20:46 | <rbuckton> | I've talked briefly (at least in the irc) about alternatives to some of the proposals for handling equality in Map keys, such as providing an "equaler" (object consisting of an `equals(left, right)` and a `hash(value)` method), the HashMap class I point to above is based on that design. |
| 20:47 | <rbuckton> | The design is inspired by `IEquatable`, `IComparer`, `EqualityComparer`, and `Comparer` in .NET, but designed around ES symbols rather than interfaces. |
| 20:48 | <rbuckton> | Either way, I'd love to have a `Temporal.Date.prototype.compareTo` method, at least as a convenience. |
| 20:49 | <ryzokuken> | that could be a simple shorthand... |
| 20:49 | <ryzokuken> | `Temporal.Date.p.comareTo = (other) => Temporal.Date.compare(this, other);` |
| 20:50 | <rbuckton> | Honestly, I'd like to see both static and prototype versions of both `equals` and `compare`. The prototype methods make it easier to interact directly with objects, and that static versions are highly useful when passed as callbacks. |
| 20:50 | <ryzokuken> | right. |
| 20:51 | <rbuckton> | I'm averse to attaching members to a prototype like that that aren't part of a spec, don't want to run afoul of the issues with "flatten" |
| 20:51 | <ryzokuken> | rbuckton: I don't think that'd be too complicated either, spec-wise or otherwise. It's just a question of "is it important enough to increase the API surface?" |
| 20:51 | <ryzokuken> | which is likely less important here, since we have a ton of stuff in the API anyway. |
| 20:52 | <rbuckton> | ryzokuken: I also bring it up because I have a library that is based on the temporal proposal because I wanted to experiment a bit. I've been updating it to the latest version of the proposal recently. |
| 20:52 | <ryzokuken> | Oh yeah, that's been a shifting goalpost for a while. |
| 20:53 | <ryzokuken> | But we'll reach a good point after the npm release in a few days. |
| 20:53 | <rbuckton> | It uses the `@esfx/equatable` APIs so that I can use `Date`, etc. as keys in a `HashMap` from `@esfx/collections-hashmap` |
| 20:54 | <ljharb> | imo a prototype method implies that directionality matters |
| 20:54 | <ryzokuken> | oh wow |
| 20:54 | <ljharb> | or rather, matters beyond inverting the result |
| 20:54 | <ryzokuken> | ljharb: I mean, that way, `equals` should be static too. |
| 20:54 | <ljharb> | like, `(a, b)` and `(b, a)` should either both be zero, or both be opposite signs |
| 20:54 | <ljharb> | ryzokuken: yes, probably true. but for equals they should always be commutative, so that doesn't feel as necessary to imply to me |
| 20:55 | <rbuckton> | Most of `@esfx` grew out of wanting to have a shared core API, and includes things like "collection" interfaces via symbols that can be shimmed onto builtins so that you can generically access members of an `Array`, `Map`, `Set`, etc. without having to special case for each type. |
| 20:56 | <ljharb> | that doesn't make much sense to me as a general goal; they often have different semantics |
| 20:56 | <rbuckton> | https://esfx.js.org/esfx/api/collection-core.html, basically has `Collection`, `FixedSizeIndexedCollection`, `IndexedCollection`, `KeyedCollection` |
| 20:56 | <rbuckton> | Yeah, true, but you can add items to an Array and a Set, but for Array its `push` and for a set its `add`. |
| 20:57 | <rbuckton> | With those (and with the relevant shim), you just do `obj[Collection.add](value)` |
| 20:58 | <rbuckton> | Or `obj[Collection.size]` rather than `Array.isArray(obj) ? obj.length : obj.size`, etc. |
| 20:58 | <ljharb> | and Map is more like a record/struct/object, where array and set are more like Lists |
| 20:58 | <rbuckton> | Correct |
| 20:58 | <ljharb> | tbh it makes me feel that treating them generically is a category error |
| 20:59 | <rbuckton> | However they still share common characteristics. Both have an inherent size. |
| 20:59 | <ljharb> | so do strings |
| 20:59 | <Bakkot> | jorendorff ping |
| 20:59 | <rbuckton> | Yep |
| 20:59 | <jorendorff> | Bakkot: Good afternoon! |
| 20:59 | <ljharb> | but making strings iterable was a mistake :-) |
| 20:59 | <Bakkot> | time to talk about built-in generators? |
| 20:59 | <jorendorff> | ljharb, Bakkot, michaelficarra, devsnek, avandolder: would a Zoom meeting be OK? |
| 21:00 | <Bakkot> | wfm |
| 21:00 | <ljharb> | yup yup |
| 21:01 | <jorendorff> | ok, let's try https://mozilla.zoom.us/j/95168117347 |
| 21:01 | <rbuckton> | A lot of popular mainstream languages work similarly for the various collection classes as well, and I've found a fair amount of use for the design even just within my own projects. |
| 21:12 | <NilSet> | reminds me of rust traits |
| 21:43 | <jorendorff> | Thanks again, iterator helpers |
| 21:43 | <jorendorff> | oops, is that a team name, do I need to order t-shirts |
| 21:43 | <rickbutton> | t-shirts should be a stage 2 requirement |
| 21:44 | <rkirsling> | niiice |
| 21:44 | <rickbutton> | * should be in tdz, whoops |
| 22:12 | <jorendorff> | I posted my understanding of our discussion in https://github.com/tc39/proposal-iterator-helpers/issues/97#issuecomment-637833039 |
| 22:12 | <jorendorff> | devsnek in particular: take a look? |
| 22:13 | <devsnek> | will do |
| 22:31 | <akirose> | Aww right now was supposed to be the newcomer’s event |
| 22:40 | <rkirsling> | oh noo |
| 22:40 | <rkirsling> | I didn't realize that was happening at all |
| 22:41 | <rkirsling> | (or do you mean, if this were in person?) |
| 22:41 | <rkirsling> | we could still do one |