2020-07-01 [18:30:58.0000] tfw the whole argument is "It's better." [18:34:56.0000] rkirsling ? [18:36:27.0000] just amused by a new issue on pipeline [18:36:44.0000] it's not harmful at any rate [18:39:54.0000] well i answered [18:43:20.0000] devsnek: oh they added a bit more info in an edit [14:13:02.0000] so how are we ordering agenda items when adding them now? [14:13:33.0000] descending, first by stage, then by timebox, then by time of adding? [14:13:51.0000] yes [14:14:18.0000] https://github.com/tc39/agendas/blob/master/2020/07.md#agenda-topic-rules, item 5: "Proposal-based agenda items should be sorted primarily by stage (descending), secondarily by timebox (ascending), and finally by insertion date." [14:14:43.0000] oh hey look at that, the rules are in writing [14:16:10.0000] oh but just for proposal items [14:16:38.0000] ah excellent [14:17:05.0000] rkirsling: those i'd expect by timebox and then by insertion date [14:17:20.0000] we could make sure that's explicit in the doc, but it's what we've been doing anyways [14:19:12.0000] I'd thought it was just insertion date myself [14:20:07.0000] i do think insertion date should trump timebox unless a tetris opportunity presents itself [14:21:29.0000] motion to encode that as our official term [14:21:35.0000] "tetris opportunity" [14:25:23.0000] the whole point of the timebox was that you get to jump the line if you're able to commit to a constrained discussion [14:25:32.0000] "by insertion date" was our pre-timebox sorting method [14:26:06.0000] oh [14:26:29.0000] that would make sense if it weren't for how poor we all are at guessing timebox lengths [14:26:38.0000] we get better over time :-) 2020-07-02 [11:12:11.0000] mathiasbynens: npm claims you have publish permissions for lodash; do you actually? and if so are you socially permitted to merge and release patches to it? JDD has been not filling that role lately and it is coming to a head this morning because npm has marked it as having a vulnerability, which causes problems for anyone with strict audit requirements and who transitively depends on lodash [12:05:10.0000] I've been thinking in setting a regular regionalized meeting to get feedback from developers speaking pt-br. We've had one similar to this in spanish and it worked great. I wonder where is the proper channel to continue this convo, the Reflector or Discourse. [12:06:45.0000] In any case, let me ping here caiolima mmarchini... am I missing anyone else online in this channel? We also have Sam Goto, Gui Hermetto, Romulo Cintra. [12:15:02.0000] sounds good (i don't look at IRC that much though) [14:41:54.0000] sigh, prototype pollution CVEs are one of the best examples of how the security industry undermines the very concept of CVEs by targeting things too broadly :-/ [14:57:14.0000] ljharb: there really needs to be a filter on what prototypes can cause the issue [14:57:46.0000] but as long as everything remains mutable 🤷 seems like they are doing the correct thing, even if it is noisey [15:00:40.0000] i don't agree they are; the bug isn't in lodash, it's in the *usage* of lodash [15:01:22.0000] imo this is the category of thing where "it can be misused" may be something undesirable, but isn't an actual security issue [15:01:44.0000] but for the small percentage of non-top-level consumers for whom it was an issue, it's a CVE for sure [15:02:01.0000] and that's why it should be a CVE [15:02:18.0000] it should be a CVE for someone, i agree [15:02:53.0000] you can't really CVE all the consumers of a library but you can CVE the library [15:03:26.0000] you can't achieve it but that's still the correct thing to do [15:03:33.0000] and marking all consumers as needing to validate what they pass is the method to get things done, but you can't say they are fixed, you can only mark the issue as mitigated by the lib [15:03:39.0000] iow they made the choice to create false positives, rather than risk missing real ones [15:03:41.0000] i don't agree it is the correct thing to do [15:03:55.0000] but the cost of making this tradeoff repeatedly *already is* that people are going to just turn off the CVEs [15:04:07.0000] not because they're noisy, but because for most consumers there simply isn't an issue [15:04:21.0000] false positives are noise but it is still the choice to disable the warnings [15:04:45.0000] imo it's better for the industry as a whole to allow real positives to go unnoticed than to undermine ecosystem acceptance of the CVE system itself by creating too many false positives [15:04:49.0000] consumers have to check if it is an issue to know if it isn't one [15:05:04.0000] (it works the same with linters; if the linter is too noisy and it doesn't feel like a real problem, people just turn off the rule/linter) [15:05:12.0000] right but they don't check, just like they don't read the itunes TOS [15:05:35.0000] sorry this is all really off topic for the channel, we can take it to tdz [15:05:50.0000] i think you want something other than a CVE, CVE is just reporting the issue not stating it affects every consumer [15:06:17.0000] fair. but github, snyk, npm audit, and all the other tools automatically assume CVE implies report [15:17:57.0000] which one is the one that can analyze the usage of code [15:18:28.0000] LGTM maybe? but github bought them and shut it down, and has a new beta for "codeQL" to replace it [15:18:38.0000] (sorry, didn't shut it down; just stopped touching it) [15:18:56.0000] ok so yeah they just need to attach codeql to their CVEs [15:19:01.0000] so it knows who to notify [15:19:30.0000] sounds like a bit more than "just" but that sounds like it'd be great :-) [15:19:45.0000] easy 15 minute task [15:19:49.0000] we have some code pattern matchers, they are too fragile [15:19:59.0000] it would still blast 90% probably [15:20:07.0000] have you tried lgtm.com [15:20:16.0000] its incredibly accurate [15:20:29.0000] s/incredibly/surprisingly/ [15:21:00.0000] not that one but things like knowing what values could be passed to _.get is... pretty big [15:32:24.0000] devsnek: it's quite inaccurate on es-abstract [15:32:30.0000] devsnek: on enzyme too [15:32:44.0000] devsnek: they have a number of heuristics that don't actually hold true in edge cases [15:34:05.0000] the only one i ever caught was document.all 2020-07-03 [21:49:07.0000] bakkot_: yes, I do have publish permissions for lodash, but it's been years since I made use of it [21:50:09.0000] I see: https://github.com/lodash/lodash/issues/4837 will take a look 2020-07-06 [12:01:36.0000] leobalter: i'm curious, is your continued work on test262 part of your job at SF? [12:03:15.0000] shu it's complicated to tell. So my main work is focused in steering the work within proposals, but the team seems value in building a good relationship through general work. [12:03:50.0000] so I manage my own time to accommodate some space for Test262, ECMA-402, etc [12:03:51.0000] i see [12:04:00.0000] thanks [12:06:22.0000] It's not a dedicated time, so I'd say it can be pretty flexible. I still associate my own identity (maybe relevance too) at TC39 w/ my contributions to Test262 but I recognize it's not my main goal to just write tests. 2020-07-07 [11:27:36.0000] leobalter: just so you know, Alexey Shvayka is a frequent JSC contributor so it's quite common that his test262 PRs will have a corresponding JSC change (whether before or after) :) [11:28:37.0000] thanks for letting me know, rkirsling [11:28:43.0000] sure! [14:20:04.0000] can someone who works at Microsoft ping sam to find out if https://github.com/samuelgoto/proposal-block-params/issues/40 is a compromised account, or something innocuous? [14:27:30.0000] goto works at G, i'll ping him [14:28:53.0000] aha, thanks 2020-07-08 [17:29:11.0000] the SameValue operation called as `SameValue(document.all, undefined)` is false correct? [17:29:49.0000] I hate document.all lol [17:45:27.0000] keith_miller correct [16:32:10.0000] akirose: can we update the ecma402 editors team? The current team should be Shane (convener), gibson042, and I. TIA! https://github.com/orgs/tc39/teams/ecma402-editors/members 2020-07-09 [11:19:29.0000] shu: re your job callback PR, since the incumbent stuff has to be captured at `.then` time, and that's when the PromiseCapability is created, could there be just a "host scheduling data" slot or something on the capability directly? [11:19:45.0000] (it'd probably need to be threaded through in a few places, ofc) [11:21:57.0000] no, i don't think it could be in PromiseCapabilities because we create capabilities ahead of .then as part of other combinators, right? [11:22:09.0000] i'm reworking it now to thread it through PromiseReaction [11:22:40.0000] put another way: not all promises have handlers that result in jobs being scheduled [11:23:14.0000] `.then` itself creates a new capability [11:23:17.0000] also i don't think i want PromiseCapabilities even *harder* to work with in specs [11:23:25.0000] right, but not all places that create capabilities need that slot [11:23:39.0000] so i don't want a slot that'll mostly be unused except in then [11:23:43.0000] sure, i'm saying it'd be in `.then`, not in NewPromiseCapability [11:23:45.0000] but i see what you mean [11:24:17.0000] hm, when are new promise capabilities created that wouldn't need that slot? [11:24:48.0000] any promise that don't ever get handlers attached to it? [11:25:17.0000] i thought capabilities are only created when attaching a handler [11:25:20.0000] no [11:25:25.0000] ohhh right [11:25:31.0000] they're created whenever we create any promise [11:25:34.0000] .then creates a new capability for the *new* promise, but the original one still had one [11:25:35.0000] gotcha [11:26:21.0000] it is a terrible name and perhaps when we can remove subclassing we can remove it and use Promises directly :P [11:50:54.0000] reminder of #tc39 [11:58:30.0000] no need, this was an intentional choice [11:58:37.0000] #tc39 is for when discussion with non-delegates is desired [11:58:44.0000] otherwise what’s the point of this channel [11:59:57.0000] i thought the point of this channel was discussing reflector stuff and discussion about things happening during meetings [12:02:17.0000] this channel is public; reflector stuff must not be discussed here [12:02:44.0000] (and ofc the only reason this channel *is* public is for legal reasons; if not for the legal requirement, it would have remained private) [12:06:30.0000] yes, please don't share actual private info like venue logistics here [12:07:14.0000] (or links to meeting notes; or people's email addresses; or any nontechnical discussions that aren't already public on github/in published notes) [13:51:24.0000] robpalme akirose: https://github.com/tc39/Admin-and-Business/issues/67 please [13:52:19.0000] i got u 2020-07-10 [14:25:28.0000] ljharb: unfortunately i think i need to move the incubator call again to thursday [14:27:10.0000] the 16th? [14:28:43.0000] shu: it works better for me and sounds like better for Caridy too based on his agenda [14:30:03.0000] ljharb: the 16th yes [14:30:11.0000] i want natalie from Project Zero to come, and friday is a conflict for her [14:30:16.0000] given this is security her presence would be invaluable [14:33:02.0000] i have a JS Foundation code of conduct meeting 9-10am on the 16th, and work bootcamp stuff 10:30-11:30, so i’ll have to miss it ¯\_(ツ)_/¯ 2020-07-11 [17:04:50.0000] i really hate scheduling [17:08:44.0000] yeah I don't envy that burden for a second [17:21:44.0000] PSA: there is *no* incubator call next week. i've rescheduled it for the week after plenary, so hopefully the respective parties who care about security can all make it [17:21:51.0000] we can all probably use the time to prep for plenary anyhow? 2020-07-13 [14:22:08.0000] shu keith_m__ bterlson https://twitter.com/leobalter/status/1282786817482223616 [14:24:20.0000] thanks for the heads up! [14:24:55.0000] leobalter: 👍🏼. Can you let me know when that lands so I can double check our import script still works? [14:26:13.0000] when I set main as default I plan to keep the master branch for some time to avoid hazards, but there is no definition yet on how we'll keep master up to date. [14:27:03.0000] leobalter: Does changing the default branch mean that cloning tracks the `main` branch instead of `master`? [14:27:32.0000] nope, and that's the biggest challenge [14:27:38.0000] If so I think we should be gtg since AFAIK our import script just clones the repo then cps everything [14:27:39.0000] oh [14:27:40.0000] ok [14:27:46.0000] so ideally I'll keep a master branch, and consider how we keep it up to date [14:27:59.0000] oh, `git clone` always defaults to master? [14:28:05.0000] no no [14:28:20.0000] you mean `git clone`? so that's easier [14:28:36.0000] it gets the default branch, so it switches to `main`, yes [14:28:37.0000] Yeah, I think its a fresh clone of the repo [14:28:40.0000] I read it wrong. [14:28:45.0000] not a pull [14:29:26.0000] fresh clones will have the easiest time [14:30:16.0000] chromium pins test262 and all other 3p deps to a specific SHA [14:30:21.0000] so i don't think branch names even matter [14:30:51.0000] and test262 is one of the manually updated dependencies, so whoever doing the manual updating needs to know, but that's about it [14:44:50.0000] keith_m__: oh yeah I forgot that that's how we do it [14:45:01.0000] the default mode always fails for me for some reason though [14:45:13.0000] so I just point the script at my pre-existing clone [14:45:30.0000] one thing that's odd is that the script does mv instead of cp [14:45:50.0000] so I need to re-sync my test262 clone after running test262-import lol [14:45:57.0000] but that's an unrelated matter [14:46:54.0000] rkirsling: I believe the mv was set for other purposes [14:48:46.0000] rkirsling: You could change it to ditto so it only works on Mac :P (maybe ditto works on linux I just never heard of it...) [14:49:29.0000] I mean tbf I only ever deal with test262-{import, runner} on my Mac but it seems bad to lean into that assumption :p 2020-07-16 [05:41:02.0000] what is a good way to get in touch with michael ficcara? [05:41:21.0000] if someone can dm me that would be great! [05:44:36.0000] %s/ficcara/ficarra [08:49:57.0000] ystartsev: dm'd [08:52:12.0000] thanks! [09:47:25.0000] "ask kevin" is also my primary method, outside of plenary [12:37:48.0000] ljharb: well my work showed more productive this way after I asked Kevin [12:37:59.0000] this week* 2020-07-18 [18:59:19.0000] leobalter: dyk who is giving the editor's report for Test262 on monday? [19:01:37.0000] I plan to report one specific thing about Test262. I’m not sure if anyone else wants to report more stuff. [19:02:12.0000] Actually, more than one thing about Test262, branch renaming and spec “bugs” [19:22:07.0000] It seems like every single scheduling constraint this meeting conflicts with every other scheduling constraiint [19:22:13.0000] making this schedule has sucked [19:22:16.0000] a ton [19:23:29.0000] we could try full randomization and keep people on their toes [19:23:35.0000] lololol [19:49:08.0000] the agenda is way, way, way overfull this meeting [19:53:01.0000] combine items into fights [19:53:12.0000] i have been tempted to do so many times. [19:53:27.0000] temporal vs .item() [19:53:54.0000] we could have a bracket [19:53:56.0000] wouldn't be a fair fight. [19:54:08.0000] i have preferences and i'm in charge of the schedule [19:54:13.0000] 😉 [19:54:14.0000] haha [19:54:19.0000] it would be interesting though [19:54:24.0000] if we could only advance one thing each meeting [19:54:28.0000] very slow of course [19:54:34.0000] what a dream world [20:21:10.0000] that would be interesting [20:21:32.0000] I would say one proposal _per level_ but [22:32:48.0000] "whichever proposals akirose thinks are most important" is not, like, obviously a worse way to decide how to prioritize things than whatever it is we currently do [22:35:22.0000] (uh, not to imply that the current mechanism is bad, just that having someone competent decide priorities by fiat is not obviously bad either) [22:46:34.0000] 😂🥰 ty Bakkot [22:53:50.0000] 😂 [04:57:06.0000] akirose: Should we have a place on the agenda, like schedule constraints, where we offer our own proposals to be lower priority/on the chopping block? [04:57:47.0000] I feel like I've contacted the chair group for this a bunch of times before, and maybe those requests are hard to keep track of [04:58:16.0000] this meeting, I'd be OK with operator overloading and extensible numeric literals to be "on the chopping block" [04:58:51.0000] I've taken up way more than my fair share of TC39 schedule time in the past... 2020-07-19 [12:22:14.0000] littledan: if you want, that’s a great idea! And very thoughtful of you too 2020-07-20 [08:21:15.0000] bterlson: forcing people to fill out attendance to get the meeting link? :P [08:21:42.0000] i like it [08:22:46.0000] I only noticed the request for RSVP on the reflector mtg 77 issue this morning [08:23:07.0000] I've "watched" the repo now to hopefully avoid that in future [08:23:19.0000] someone mentioned an "event calendar" on that same thread [08:23:32.0000] where is that? I don't see anything in the how-we-work repo [08:24:23.0000] brad4d: https://github.com/tc39/Reflector/issues/290 [08:25:20.0000] thx [09:40:06.0000] the link appears to be to edit the form itself and not to fill it out [09:44:08.0000] bterlson: how do i change my name to say (OpenJS Foundation) instead of (Guest) [09:53:47.0000] devsnek do you not get an option to set your name when joining the meeting? [09:53:58.0000] I put in "Gus Caplan" [09:54:02.0000] it added the (Guest) [09:54:55.0000] > Ross Kirsling (Playstation) (Guest) [09:55:09.0000] i see some people with two "(Guest)"s [09:55:23.0000] and a few with none, including me, but i signed in as a guest [09:55:40.0000] chicoxyzzy: ooh, good move putting your notes abbreviations in your name [09:55:41.0000] you think its live account related? [09:55:44.0000] maybe [09:55:56.0000] i did not sign in and i have (Guest) next to my name [09:58:08.0000] I have Guest too [09:58:13.0000] weird [09:58:31.0000] i left to change my name and now i'm sitting in the queue - i assume it's just manual? [09:59:47.0000] bterlson: ^ [10:03:16.0000] am i the only one still waiting to get in? [10:03:26.0000] nvm, i'm in [10:04:21.0000] For the meeting scheduling, could we move custom numeric literals to after records and tuples + symbol as weakmap keys? [10:04:28.0000] How do you actually get into the video conf? (Assuming teams is up) [10:04:38.0000] I'm worried the latter two topics could run over time, and I'm fine with that time being cannibalized from custom numeric literals [10:04:56.0000] (btw if there's someplace else I should make this request, let me know) [10:05:09.0000] apaprocki https://github.com/tc39/Reflector/issues/288 links a google form you fill out to get the link [10:05:13.0000] and then you click the link [10:05:30.0000] Hm yeah I did that but didn’t get a mail [10:05:42.0000] it doesn't send you mail [10:05:51.0000] it just has the link on the page that results from clicking submit [10:06:12.0000] Ah ok must have sped through it [10:06:55.0000] apaprocki dm'd [10:11:25.0000] that delegates info form has Thursday after Friday [10:11:27.0000] horrifying https://gc.gy/62970054.png [10:11:34.0000] jinx [10:11:44.0000] lol 3 seconds [10:13:17.0000] BTW what do people think of replacing first name/last name on the forms with just "name" next time? Not all cultures have a first name/last name split [10:13:41.0000] this is actually something I previously raised to Ecma as something we should also avoid in forms [10:13:49.0000] just name is easier to manage i think anyway [10:16:51.0000] +littledan I agree, let's just ask for "name" [10:16:57.0000] +1 [10:17:24.0000] google "falsehoods programmers believe about names"; it's a great reference for those who haven't seen it :-) [10:18:02.0000] shout out to my friend whose legal name is er3in [10:20:37.0000] what is this notify command? [10:21:01.0000] notify command? [10:21:59.0000] like the irc `/notify`? [10:23:22.0000] devsnek: can you tell me more? I've been researching this topic and it seems like most places don't let you have anything novel in names? [10:23:46.0000] I want to change my legal name to have a null character in the middle or a zwsp or something [10:23:48.0000] is it 3 as in 'ayn? [10:24:28.0000] bterlson: born in the us. apparently her birth certificate was submitted on new years eve and not checked properly [10:24:40.0000] omg [10:24:47.0000] FYI, Microsoft Teams apparently has an option for "Turn off incoming video" if Microsoft Teams is eating your CPU/RAM for breakfast :) [10:25:11.0000] drousso: does that help? [10:25:13.0000] rkirsling: it was supposed to be silent but she goes by "erthreein" [10:25:36.0000] well pronounces it like that, still spells it er3in [10:25:56.0000] michaelficarra it seems to have helped for me! but not sure if that was just circumstantial 😅 [10:27:18.0000] it would be cool to get some stats on the github pages specs [10:27:29.0000] drousso: I am trying it now [10:27:52.0000] it would be nice to have "just show video for person speaking" [10:31:02.0000] michaelficarra FWIW (and you probably see this too), you can still see their shared screen [10:35:21.0000] do we have beginners in the room who would appreciate simplifications of topics that are discussed? [10:40:05.0000] ystartsev: I'd be interested, what form are you thinking that would take? [10:40:40.0000] I (and others who are willing) would translate what is being discussed in a beginner friendly way [10:41:01.0000] clear up any definitions [10:41:02.0000] etc. [10:41:10.0000] I can't get the /notify command working in irccloud. Does it work for anyone else? [10:41:31.0000] littledan: hm, not working for me either [10:41:54.0000] hm, maybe freenode disabled it [10:43:02.0000] could the chairs recommend another way to contact them? [10:44:13.0000] ystartsev: yeah speaking for me, that'd be really helpful [10:44:15.0000] (looking into it; it might be irccloud and not freenode; if so i'll take it up with them) [10:44:41.0000] turns out it's `/notice` not `/notify` (sorry if your IRC client makes this intrusive) [10:44:47.0000] ^ [10:45:15.0000] littledan: in case you missed that - `/notice` [10:45:17.0000] ljharb: could you post the slides from your status update in the notes? [10:45:22.0000] sure [10:45:24.0000] ah, thanks! [10:46:07.0000] yeah, that worked I think [10:48:03.0000] sffc: I made a slideshow for the rounding behaviour PR and added it to the agenda separately but if we get consensus about it right here, I suppose we could save some time? [10:49:40.0000] seems not weird to me [10:49:57.0000] link for that issue: https://github.com/tc39/proposal-smart-unit-preferences/issues/10 [10:52:43.0000] It only affects the default value behaviour on an edge case. [10:54:34.0000] sffc: littledan: thanks! [10:56:00.0000] rwaldron: could you post the slides for the test262 status update in the notes? [11:13:28.0000] mpcsh: i invited you to #tc39-beginners, i will try to do a constant stream in there [11:13:40.0000] sweet! thank you! [11:14:10.0000] anyone who wants to help people on board or whatever please feel free to join, also if you are new-ish or have definitions questions [11:20:05.0000] shu: strong agree with your comment there [11:22:45.0000] can't hear waldemar at all [11:22:48.0000] is it just me, or is waldemar's audio garbled? [11:22:50.0000] was robotic [11:23:04.0000] same here [11:23:08.0000] whew, I thought it was just me at first [11:23:40.0000] that's how you know opus isn't being used [11:45:10.0000] +1 waldemar [11:49:38.0000] Either side will surprise parts of people, so only syntax error could protect people [11:51:47.0000] the syntax error would probably surprise a lot more people than one of the choices, tho [11:53:19.0000] At least it will tell them it may be not behave like u think [11:54:40.0000] sorry for the "proposer with weak opinion" bit :p [11:55:14.0000] direct eval is enough of a power-user feature that I think we can not worry about people who are specifically intending to get direct eval with new syntax being surprised by it not working [11:55:25.0000] And eval?.() actually have no solid use cases. so we'd better ban it [11:57:45.0000] is there a PR or issue for this item? where is it on the agenda? [11:58:31.0000] @shu https://github.com/tc39/ecma262/issues/2062 [11:58:45.0000] no, not that one [11:58:48.0000] the one leo is presenting right now [11:58:54.0000] shu: way at the bottom of the agenda [11:58:54.0000] https://github.com/tc39/ecma262/issues/2090 [11:58:58.0000] ah thanks [11:58:59.0000] https://github.com/tc39/proposal-numeric-separator/issues/49 [12:01:10.0000] what is the etiquette around muting someone who is making noise and doesn't seem to know they are unmuted? [12:03:51.0000] I mute aggressively, personally. [12:04:27.0000] anyone happier with teams this time around? There have been a few updates since last meeting... [12:05:21.0000] bterlson: the biggest problem for me is that (on iOS at least) it's impossible to change which 4 people i'm looking at. i can't hide "folks with no video" nor can i scoot it through the list [12:06:32.0000] Is there way to show the name of speaker in teams? [12:33:14.0000] bterlson: Teams are still going to town with the CPU usage if I use it as a native app on Mac OS [12:33:44.0000] I see myself forced to use the browser version, which is not problematic [12:48:34.0000] let's see how Teams deals with me building JSC on the same machine [12:49:58.0000] ystartsev: yeah you can say it continues from where the Berlin presentation left off, maybe? [12:54:39.0000] There some uncertainty in the last meeting regarding whether internal slots with non-primitive values pose a problem to avoid. [12:54:58.0000] Was some resolution reached around that? [12:55:22.0000] I believe someone said they would ask MM to present his views on this. [12:55:37.0000] but I didn't see that when I skimmed through the agenda. [12:55:52.0000] brad4d: yes [12:56:05.0000] there was, there are two items on the agenda related to this [12:56:12.0000] "documenting intrinsics" and "specific intrinsics [12:56:21.0000] i don't know if we will get to them [12:56:35.0000] but the short story is that ses group dropped it's objection afaik [12:57:04.0000] do you mean "documenting invariants"? [12:57:07.0000] There's a small write up on the Intl docs [12:57:08.0000] gah [12:57:09.0000] sorry [12:57:15.0000] _invariants_ in both cases [12:57:19.0000] https://github.com/tc39/proposal-intl-segmenter/issues/96#issuecomment-661008571 [12:57:22.0000] shiny, thx for clarifying [12:58:34.0000] starting in 3 mins [13:07:30.0000] Does "NonOctal" specifically mean "starts with a 0, but isn't an octal?" rather than just "not an octal"? [13:07:54.0000] brad4d: yeah [13:08:11.0000] its a very scary part of js [13:08:20.0000] it's specifically when 8 or 9 pulls a switcheroo in an otherwise octal context [13:08:25.0000] bterlson: mic might be accidentally unmuted [13:08:45.0000] abbreviated "noctal" [13:08:52.0000] i'm excited that the rewrite of engine262 doesn't include legacy octals at all [13:08:55.0000] (because it's catchy, I assume) [13:09:18.0000] devsnek: doesn't that translate to "I'm excited that engine262 doesn't implement the whole spec" though [13:09:26.0000] annex b? [13:09:43.0000] we have consensus to pull the non-regex/html comments part of annex B into the main spec [13:09:48.0000] editors are just busy with other stuff [13:09:50.0000] if someone moves it out of annex b i will be very excited to implement it [13:09:53.0000] there is so much editorial work to be done [13:10:13.0000] ooh, I am excited for this presentation [13:10:16.0000] devsnek: ahh okay [13:10:24.0000] Bakkot: same! [13:10:24.0000] also excited for this pres [13:10:27.0000] yay let's get cognitive [13:10:32.0000] 🧠 [13:10:50.0000] i'm not used to using my brain on the job [13:10:57.0000] lol [13:12:39.0000] we've actually made a lot of progress reducing this "secret language" over the years lol, it used to be sooooo esoteric [13:12:49.0000] this is where we learn tc39 is a programming language design noob [13:13:33.0000] michaelficarra: yeah I feel like those particular examples are at least "it means what you think it means" [13:13:35.0000] :) [13:14:30.0000] to be clear, I'm not trying to say we don't have plenty of examples of "secret language" today, just that they used to be worse and more common [13:14:39.0000] yeah [13:14:43.0000] also we started writing them down: https://github.com/tc39/how-we-work/blob/HEAD/terminology.md [13:15:28.0000] "worth its own weight" is a general english idiom IME, right? [13:15:51.0000] ^ yes, but what "weight" means in this context is complicated [13:15:56.0000] I love this use of "viscosity" [13:15:57.0000] (is my take) [13:16:10.0000] michaelficarra: +1 [13:16:19.0000] it is interesting that it's called viscosity instead of liquidity [13:16:35.0000] heh, guess that's a question of vantage point [13:16:42.0000] shu: i guess its whether you're thinking of "worth the pros" vs "worth the cons" [13:17:02.0000] devsnek: right: https://en.wikipedia.org/wiki/Markedness [13:17:41.0000] I guess JS tends to have a viscosity level resembling molasses [13:17:57.0000] lol i've found the opposite [13:18:50.0000] “ viscosity” is really a secret language itself [13:19:03.0000] js has the viscosity of helium [13:19:11.0000] i would say I find it easier to make changes in small JS programs than in e.g. Java, but usually harder to make large changes [13:19:14.0000] oooh no CDN is a terrible acronym [13:19:16.0000] oh noo it's an overload for CDN [13:19:30.0000] Cognitive Delivery Network [13:19:37.0000] rkirsling: I can see it both ways, typed FP languages are really rigid, but they also guide your hand when refactoring [13:19:55.0000] yeah that's basically my experience [13:19:58.0000] not just FP [13:20:01.0000] I wonder if I misunderstood the term then [13:20:09.0000] vs. malleability / rigidity [13:20:25.0000] yeah it depends on whether you define viscosity as "ease of making local changes" or "ease of making changes that satisfy some constraint, correctness, or type soundness, etc" [13:22:18.0000] omg I love the idea to enumerate our language design guidelines [13:22:43.0000] michaelficarra: we've had the rationale repo for a long time, it's just been really hard to get off the ground [13:23:24.0000] michaelficarra: i'm skeptical of utility, because i don't think we can really whittle them down [13:24:22.0000] shu: it doesn't need to be 100%, just a "checklist" as Felienne puts it, of things we should consider [13:24:38.0000] yeah, like "these are the battles one often needs to fight" [13:25:26.0000] er like "the perspectives one would want to have arguments toward" [13:25:55.0000] ohh wow I thought it was viscosity of *design* [13:26:01.0000] not of *use* [13:26:03.0000] my bad [13:27:16.0000] i love that this is called a "maneuver" [13:28:17.0000] ystartsev: "a double equals b" [13:28:25.0000] or "a triple equals b" [13:29:00.0000] "abstract equality" and "strict equality" [13:29:37.0000] "abstractly equal" and "strictly equal" don't roll off the tongue nearly as well to me :-p [13:30:24.0000] "equal" and "eichwal" [13:30:28.0000] I don't think the spec-internal names are any worse than "double/triple equals" lol [13:30:32.0000] triple equal actually not strict enough (+0, -0, NaN) :-) [13:30:40.0000] double/triple is how it's already colloquially spoken aloud [13:30:49.0000] devsnek: eichwal, wow [13:30:50.0000] haxjs: SameValue [13:30:55.0000] ljharb: i know i'm very proud [13:32:06.0000] that's amazing [13:32:09.0000] I really hope we can have a Truely Strict equal ... maybe `a is b` which use `Object.is` semantic [13:32:13.0000] eichwal would be == though, yeah? [13:33:08.0000] "equal" and "typo: you forgot a =" operators [13:33:41.0000] devsnek: also can you tweet that so that I can RT it without taking credit from you [13:34:11.0000] lol [13:36:18.0000] rkirsling: one sec, putting into drake meme format [13:36:23.0000] Can we mute Caio? [13:37:46.0000] is anyone else finding WH's language on this topic uncomfortably aggressive? [13:37:52.0000] can delegates not talk in #tc39-editor-group ? [13:38:09.0000] I was not aware of that channel [13:38:24.0000] bradleymeck: I think you should be able to [13:38:31.0000] mpcsh: Yes, I agree [13:38:42.0000] I also agree [13:38:47.0000] bradleymeck: oh sorry, I thought you were responding to me and saying that discussion was happening in that channel [13:39:43.0000] rickbutton: if I wanted to stop using `x == null`, would I start using `!!(x ?? !0)`? [13:39:48.0000] "you've actually made it worse" was particularly unacceptable to me [13:40:03.0000] ditto "[the definitions] are unusably fuzzy" [13:40:47.0000] michaelficarra: `/null|undefined/.test(x)` is the only valid way going forward [13:41:39.0000] rickbutton: doesn't that fail for "null"? [13:41:47.0000] yes :P i was joking [13:41:54.0000] michaelficarra: i don't appear to be able to mmm [13:42:19.0000] bradleymeck: I see you in there [13:42:28.0000] michaelficarra: can't send messages [13:42:41.0000] ooohh [13:42:57.0000] our linter rules disable == in all cases, and our style guide suggests checking for null and undefined explicitly, but really the callee should only return one or the other, not both, and should be documented [13:43:24.0000] most common linter configs disable `==` except when it's `== null`, fwiw [13:43:26.0000] the only thing I use `==` for is `== null` [13:43:47.0000] I don't really have a strong opinion either way, if I read `== null` i will know what it means [13:43:54.0000] put another way, i don't know any common linter configs that allow `==` for anything non-null [13:46:51.0000] really hope we fixed == as JS 1.2 :-P [13:50:07.0000] ljharb: how about "equal-equal" and "equal-equal-equal" for names? [13:50:57.0000] we shorten "2 and 2 and 2" to "2 cubed" so why not shorten those to double and triple :-p [13:51:38.0000] so we will face the typo problem for eq-eq and eq-eq-eq just like == vs === :-P [13:52:05.0000] trying to pronounce eq-eq-eq reminds me of the Knights of Ni [13:52:13.0000] ljharb: "2 and 2 and 2" is 6 [13:52:31.0000] oh lol sorry, wasn't paying full attention [13:53:17.0000] 🙃 [13:56:44.0000] robpalme: update the queue? [13:58:57.0000] bradleymeck you had that proposal for `private` decls outside of class bodies, yeah? [13:59:03.0000] is that still live? [13:59:12.0000] Bakkot: jridgewell I believe is still handling it [13:59:21.0000] cool, same question to jridgewell [13:59:23.0000] i just wanted to find someone to do it [14:06:08.0000] whoa, new VariableEnvironment, hm [14:06:49.0000] feel weird about that a bit [14:06:53.0000] very weird [14:06:55.0000] would prefer disallowing `var` maybe [14:07:05.0000] just don't do anything with var [14:07:05.0000] any concerns with letting them hoist? [14:07:13.0000] Yes, it's still alive [14:07:13.0000] ya just let it hoist [14:07:18.0000] ehh... class is kind of a function boundary is the reason I assume [14:07:25.0000] But waiting for Class Fields to land before I bring it back. [14:07:34.0000] the constructor is a function boundary [14:07:40.0000] the "static part" is also? [14:07:47.0000] i don't have that intuition in any sense [14:07:52.0000] same [14:08:11.0000] someone should get on the queue [14:08:31.0000] I think that doesn't need to be solved at this stage [14:08:37.0000] but worth bringing up if you care a bunch I guess [14:08:46.0000] shu well it changes the scoping of `this` [14:08:52.0000] which is a lot like being a function boundary [14:09:00.0000] this being different is also weird [14:09:10.0000] Bakkot: interesting, would need to stew on that [14:09:35.0000] Bakkot: that seems better solved to me as requiring to use class name itself, unbind this, so i can think of the static block as a run-once, well, block [14:09:38.0000] but maybe i'm missing something [14:10:25.0000] i suppose consistency with field initializers, but those are the odd ones out in my mind [14:10:53.0000] i don't get why those need `this` either [14:12:26.0000] instances fields definitely do [14:12:55.0000] static field initializers [14:13:06.0000] it's nice to not have to repeat the class name [14:13:09.0000] within the context of static it is weird to bring `this` into it [14:13:10.0000] imo [14:13:22.0000] i'd prefer "class access expressions" over using `this` tho [14:13:44.0000] is that the uh [14:13:46.0000] `class.x` thing [14:13:59.0000] yeah [14:14:07.0000] +1 on that [14:14:25.0000] since that proposal exists i don't see a point in binding `this` [14:15:03.0000] it doesn't exist yet tho [14:15:16.0000] what doesn't exist yet [14:15:29.0000] that proposal has not advanced [14:15:33.0000] to stage 4 [14:15:38.0000] yeah [14:15:40.0000] right. it's still stage 1 iirc [14:16:03.0000] if it was stage 4, then i'd have wanted static class fields to not have `this` available either [14:16:03.0000] i'm saying we should recognize the value of that here instead of hacking it in with `this` [14:16:23.0000] but since static class fields already bind the `this` i think it'd be very weird for static blocks not to [14:16:29.0000] class.this.* is > than class.* [14:16:39.0000] lol [14:16:44.0000] not even joking [14:16:50.0000] i don't understand [14:16:54.0000] isn't that just `class.*` [14:16:55.0000] what is class.this? [14:17:03.0000] `class.` is supposed to be a way to reference the current class constructor [14:17:43.0000] so like, `class C { static x() { return class.x === C.x; } } C.x() // true` [14:17:51.0000] you're suggesting `class.this.x`? [14:17:51.0000] I mean what is `class.this` , it should be `this` property on the class? [14:17:53.0000] devsnek: except it leaves space for any other meta-properties we may want [14:18:02.0000] `class.this` definitely should be the "this" property on the class [14:18:20.0000] bradleymeck: what else would we want tho? the class is the constructor, conceptually [14:18:34.0000] `class.#x` would work too, i assume [14:19:26.0000] decorator stuff, exposing other things that aren't obvious (heritage?) [14:19:45.0000] heritage is Object.getPrototypeOf(class) [14:19:56.0000] not if you don't use extends [14:20:08.0000] then its not real heritage [14:20:11.0000] and not our problem [14:20:15.0000] it still inherits XD [14:20:47.0000] we can argue about various possible futures, but if i got some time i could probably ramble on with ideas of things i might want to store [14:20:58.0000] if we want it to be static constructor why not just `static constructor` [14:21:02.0000] bradleymeck: `class.@decoratorStuff` [14:21:13.0000] oh i guess that overrides the constructor property [14:21:15.0000] sigh [14:21:24.0000] anyway if that's the goal it should be a lot clearer [14:22:27.0000] Could we use `static.x` syntax instead of `class.x` ? [14:23:01.0000] we could, but i don't see why that'd be clearer [14:23:10.0000] haxjs: what's the advantage to using `static.`? [14:23:25.0000] mapping to static declaration I think. [14:24:32.0000] rbuckton: maybe my concern can be addressed by simply changing the name of the feature to "static constructor" [14:24:37.0000] haxjs: worth filing on https://github.com/tc39/proposal-class-access-expressions [14:24:50.0000] and communicating it both inside and outside of committee using that, while keeping the block syntax [14:25:12.0000] using a function syntax would be interesting [14:26:27.0000] shu: I named it based on its syntax, I was worried calling it `static constructor` would be possibly confusing because `static constructor () {}` is legal: https://usercontent.irccloud-cdn.com/file/tEbveTEq/image.png [14:27:07.0000] this is one of the most arcane parts of the web platform [14:27:13.0000] hope y'all are paying attention [14:27:23.0000] this is all i think about [14:28:15.0000] rbuckton: `static #constructor`? [14:28:27.0000] maybe too much magic [14:29:34.0000] @ljharb filed https://github.com/tc39/proposal-class-access-expressions/issues/3 [14:29:57.0000] Not a big fan of `static #constructor`, a lot to write, hard to remember, and too easy to do the wrong thing and forget the `#` [14:30:08.0000] haxjs: ty [14:30:34.0000] rbuckton: yeah idk, i would be on board with the static constructor idea if it was clearer that it was like a function [14:30:35.0000] also static blocks have precedent in languages like e.g. Java [14:30:50.0000] I prefer using the same syntax for things where it makes sense to do so [14:31:01.0000] like even if we did getter style syntax `static ( ) Block` sort of thing [14:31:38.0000] What will happen if have multiple static block? [14:31:38.0000] if its not a function i don't think it should do function things [14:31:53.0000] haxjs: i assumeearly error like multiple constructors [14:32:39.0000] the presentation said early error [14:33:03.0000] Java seems allow multiple static block [14:33:22.0000] The problem with `static.x` is that `static` isn't a reserved word, so we could break existing code. [14:33:32.0000] ah right [14:33:49.0000] rbuckton static is reserved word in strict mode, and class code is strict [14:34:03.0000] ``` [14:34:03.0000] let static = 1; [14:34:03.0000] class C { [14:34:03.0000] static { [14:34:03.0000] static; // 1 or `this`? [14:34:04.0000] } [14:34:04.0000] } [14:34:05.0000] ``` [14:34:20.0000] `static` by itself would be 1 [14:34:28.0000] static in a class body is a reserved word [14:34:32.0000] but if `let static = { x: 1 };` then `static.x` would be the question [14:34:42.0000] fwiw I like `this` a lot better than this new syntax [14:34:50.0000] devsnek: so `x = static.y;` is invalid? [14:35:00.0000] not valid in class [14:35:08.0000] ljharb: yes [14:35:24.0000] hm [14:35:26.0000] static is a reserved word in strict mode [14:35:29.0000] I guess `static` is reserved in strict, but still it feels weird to reuse it. [14:35:30.0000] and class bodies are strict [14:35:33.0000] how can we ensure that people use the queue? it's highly disruptive and burdensome on the notetakers when people interrupt a presentation for what should be entered as a clarifying question on the queue. WH has done this twice today, despite my earlier reminder to use the queue after the first instance. [14:35:36.0000] that being said [14:35:40.0000] i don't like using `static` for this [14:35:49.0000] +1 for `class` [14:35:56.0000] Neither do I. I proposed `class.x` because there would be no ambiguity [14:36:04.0000] +1 [14:37:48.0000] Well, that's it for me this TC39, I won't be available for the rest of it. Thanks all [14:37:57.0000] rbuckton: thank you sir :) [14:38:26.0000] bradleymeck: could you bind the function constructor or eval with the first argument being the string [14:39:18.0000] mpcsh: Please stop the personal attacks [14:41:01.0000] wsdferdksl: (assuming this is Waldemar) I didn't realize you were on IRC, will send a DM [14:44:33.0000] shu: mark is saying if the base is null, delegate to the surrounding realm [14:46:32.0000] s/base/referencingScriptOrModule/ [14:47:04.0000] devsnek: i understood mark as saying delegate to the [[Realm]] that the eval came from [14:47:06.0000] a second please [14:47:16.0000] devsnek: thats unclear as the behavior seems to call the hook with the execution context that is enqueueing the job [14:47:38.0000] an indirect eval should have the correct realm [14:48:34.0000] shu: that would be the active realm afaik [14:49:08.0000] devsnek: question is what if it itself doesn't have an active script? [14:49:50.0000] at that point it is html's problem right? you have a realm that came from some page [14:50:28.0000] the specificity is "the entire page" [14:52:01.0000] it's not html's problem [14:52:13.0000] i mean it is, but it needs JS to tell it when to do the capture [14:52:23.0000] which is what this is [14:52:31.0000] bradleymeck: i am pretty sure incumbents are not polyfillable [14:52:39.0000] given the active realm doesn't that give you the correct incumbent [14:52:41.0000] i wouldn't expect any host hook things to be polyfillable atm [14:52:55.0000] you can't polyfill the unhandled rejection hook either [14:53:05.0000] bradleymeck: the backup incumbent stack, that is, nor the active script check for dynamic import() base url [14:53:12.0000] bradleymeck: the question to you is why is that a goal? [14:53:21.0000] ljharb: the problem is that if you polyfill Promise.prototype.finally it won't match a native impl ever [14:53:39.0000] bradleymeck: that's already true, because of `await` [14:54:06.0000] well, i guess since it calls into a native `.then`, it'd work fine [14:54:20.0000] bradleymeck: that's a different problem, which is HTML's implementation of the hook isn't polyfillable, and therefore you can't polyfill a perfect replica of one integrated with HTML [14:54:31.0000] ljharb: it would be relative to the polyfill not the document from my understanding [14:54:32.0000] bradleymeck: but in a host where there's no unhandled rejection behavior, it's not possible to provide that behavior [14:54:45.0000] bradleymeck: oh sorry i'm talking about unhandled rejections; not this one [14:55:02.0000] bradleymeck: i'm trying to claim that it's not a reasonable expectation to be able to polyfill any host hook [14:55:06.0000] shu: sure, but i'm just coming from node's perspective not purely HTML [14:55:22.0000] and the behavior isn't necessarily problematic, but very unexpected [14:55:40.0000] and that makes me not want to move forward on my level of review for this meeting [14:56:21.0000] if it just errored instead of resolving against the user code that is acting like native code, that seems fine [14:56:35.0000] what errors? i am confused [14:56:48.0000] alright we have four minutes to push monads through [14:56:50.0000] like the proposal is to add a host hook that by default is a nop, not to add any specific behavior [14:57:19.0000] shu: correct, and I am unclear on why we would ever want to have the expected usage of the hook behavior [14:57:27.0000] the expected behavior seems to misalign with my expectations [14:57:45.0000] shu: i don't get why %eval%.[[Realm]] isn't the correct realm [14:57:45.0000] i do want to fix the code example, but the solution seems off [14:58:03.0000] bradleymeck: because the web already works this way for all web APIs, and firefox already works this way for Promises, and i want to reflect that reality in the spec instead of stringing together willful violations [14:58:21.0000] bradleymeck: i'm fairly confident there isn't a significantly cleaner way to layer this [14:58:28.0000] sorry for the technical issues, everyone. My computer seems to be really acting up today but I'm avoiding a restart because kernel updates 😅 [14:58:39.0000] shu: I'd agree but I don't really want hosts to diverge here and thats what the hook is encouraging [14:58:43.0000] ryzokuken: was fine tbh [14:58:55.0000] devsnek: thanks [14:59:00.0000] also, i hate pulseaudio [14:59:03.0000] but yes [14:59:29.0000] shu: in part because, it is soo edge casey already, does it even need to be fixed? [15:00:06.0000] do newer web APIs even have this behavior or are we trying to align with what is considered bad practice these days [15:00:20.0000] bradleymeck: yes, if you use WebIDL you basically have this behavior [15:00:42.0000] bradleymeck: it needs to be fixed largely because HTML folks feel strongly that finalizers and promises should align with WebIDL here [15:00:50.0000] and i'd rather give them a clean point than willful violations [15:01:08.0000] firefox especially feels that finalizers and promises should track incumbents [15:01:10.0000] shu: i'm not really sure how user code or node could align with that [15:01:24.0000] bradleymeck: they don't, that's why it's a host hook [15:01:32.0000] full virtualizability is not a goal [15:01:40.0000] i understand you might desire that, but that's not true today [15:01:42.0000] shu: node doesn't need virtualizability [15:01:53.0000] sorry i was responding to the "how user code could align with that" [15:01:53.0000] shu: just the host itself seems to be against this pattern [15:02:08.0000] node COULD align with it by providing some privileged API that's like "capture incumbent" [15:02:26.0000] we have no such existing APIs, and that seems very odd to me [15:02:37.0000] do you have a rejection handler API, right? [15:02:42.0000] err, s/right// [15:02:43.0000] yes [15:03:10.0000] this would be along those lines if it was important to capture the backup incumbent stack behavior [15:03:25.0000] i don't understand that last sentence [15:04:22.0000] if it was important for node to capture the backup incumbent settings object stack behavior that HTML exhibits, then node could expose an API like "capture incumbent" and "restore incumbent" along the same lines of the already-provided rejection handler API [15:05:45.0000] i am unclear on what we need to capture, we already get the hook via the realm. I don't think stating everything related to "backup" + "incumbent" + (the settings object) is helping [15:06:05.0000] i'm familiar with settings and have some understanding of incumbent [15:06:36.0000] i tried to abstract all of that away with a notion of "some ambient state at the point of passing a callback to an API that eventually schedules the job" but that's even harder to talk about, i guess [15:06:44.0000] but none of this seems to align with my understanding of how this hook is supposed to enable a use case except for a very specific things for HTML and cause other hosts to have potentially drastic differences in how import() works [15:07:18.0000] ah, is that the actual concern, for import() divergence? [15:07:33.0000] shu: i think as long as we can align on what wouldn't cause node libs to require themselves to use privileged APIS and manage their own contexts it would be fine [15:07:36.0000] shu: yes [15:07:54.0000] i think mark's is around grabbing the data from the execution context itself [15:07:59.0000] which seems... bad to me [15:08:02.0000] but not fatal [15:08:04.0000] bradleymeck: do you have time to try to work through that right now? [15:08:11.0000] nope, gotta feed a kid [15:08:21.0000] k, let me schedule something for later then [15:08:25.0000] k [15:16:20.0000] devsnek: as for why eval's [[Realm]] wouldn't work, please read through the convoluted examples in https://html.spec.whatwg.org/#incumbent [15:17:02.0000] shu: I was looking through them, I don't get why it wouldn't [15:18:00.0000] the last one, with iframes [15:18:19.0000] you could schedule a Promise.resolve('import("whatever")').then(otherFrame.eval) [15:18:23.0000] the incumbent should still be yourself [15:20:50.0000] shu: I think the point was in that case it should be the other frame [15:21:09.0000] what do you mean "it should"? [15:21:21.0000] idk, a value judgement [15:21:34.0000] that behavior is not up for debate, it is what it is today [15:22:33.0000] only in firefox though right? [15:22:53.0000] no, for all web APIs (setTimeout) in all browsers, and for Promises only in Firefox [15:23:50.0000] so the question is, if we refuse to add these hooks to ecma262, there'll always be this corner case that makes Job-queuing APIs in ecma262 different from those that use WebIDL [15:24:08.0000] that's one outcome [15:24:22.0000] but there's no outcome where we, as tc39, can legislate the behavior away [15:24:59.0000] as long as promises observably stay the same, html can say they do additional things right? [15:25:37.0000] i don't understand what you mean by "observably stay the same" [15:26:07.0000] like can't it just say "insert this logic" [15:26:17.0000] that's not violating ecma262 [15:26:26.0000] insert this logic in the middle of two algorithmic steps in a builtin? [15:26:45.0000] I guess something like that, yeah [15:27:13.0000] technically it can do whatever it wants, but myself, as a 262 editor, and the html editors, want a well understood, structured way to interface the specs [15:27:16.0000] thus host hooks [15:27:28.0000] this is not a question of expressivity. willful violations are also possible [15:27:50.0000] yeah it just seems like a very undesirable behaviour we wouldn't want to encourage [15:28:00.0000] I'm not expressly against the hooks [15:28:01.0000] i lament that we will intentionally create a harder to read document because of a lack of real argument [15:28:12.0000] i don't get this encouraging point [15:28:23.0000] you can almost do whatever you want with the module specifier right now [15:28:35.0000] but you weren't primed with that whatever's done right now is "weird and arcane" [15:29:04.0000] like within the design of the language you'd want the "context" to be determined by the eval, not where the string was written [15:29:12.0000] maybe that's what mark meant by dynamic scope [15:29:35.0000] that is what he's meant, but it's also not up to him or tc39 to decide, because that weirdness is already here with setTimeout [15:29:45.0000] or at least i also believe that's what he meant [15:29:51.0000] also it's not where the string is written, it's where the eval was passed [15:32:05.0000] theoretically what happens if js stuff determines the incumbent differently [15:32:40.0000] what does that mean, it provides a different default implementation than no-op? [15:33:07.0000] differently from setTimeout [15:33:46.0000] theoretically nothing happens because theoretically there is no default implementation of job scheduling and running [15:34:12.0000] I mean what if it works like not firefox [15:35:31.0000] then patterns like passing `postMessage.bind(whatever)` into Promise#then will behave differently from passing it into setTimeout [15:35:41.0000] a rare gotcha [15:35:56.0000] it is also possible that HTML and browsers decide, well, we'll just do the behavior anyways without host hooks [15:36:25.0000] in which case both will work the same but the specs will unfortunately obscure this fact [15:36:38.0000] you could say all new APIs do the active realm trick and timers are the exception [15:37:00.0000] but it's not just all setTimeout, it's *all* WebIDL that takes callbacks [15:37:15.0000] and you could say that, but does that serve the web dev better than aligning? [15:37:23.0000] i haven't heard a good argument that it does [15:37:46.0000] I guess I'm having trouble imagining when any of these options provide any use to a web dev anyway [15:39:12.0000] fair, but having complete interop semantics is the general strength of the web platform, and i'd like to keep that [15:42:19.0000] I assume the web breaks if you change webidl to use the builtin function's realm [15:42:26.0000] for everything [15:45:01.0000] that's the assumption 2020-07-21 [09:52:42.0000] same meeting link as yesterday, right? [09:53:23.0000] I don't think any of us have that link anymore though [09:53:29.0000] it's going to need to be posted [09:53:37.0000] you can go through the form again [09:53:45.0000] is that desired though? [09:53:52.0000] bterlson: ^ [09:54:04.0000] rkirsling: they said yesterday you can fill the form out twice [09:54:09.0000] oh [09:54:12.0000] alright [09:54:14.0000] it doesn't hurt anything we can dedupe as needed [09:56:07.0000] so much stage 4 this meeting [09:56:08.0000] very exciting [09:57:50.0000] Could we just post the link in the Reflector issue? [09:58:05.0000] jridgewell: the goal was that nobody saw the link who hadn't filled out the attendance form [09:58:38.0000] (from what i understand) [10:00:15.0000] I filled it out a second time, and then bookmarked the final link. [10:00:49.0000] the "thanks for filling out the form" page is bookmarkable, ftr [10:01:08.0000] or at least, refreshing it loads it fine [10:01:42.0000] I wish the Teams client could remember your previous meeting link [10:06:32.0000] 🎉 [10:06:36.0000] that was fast [10:09:41.0000] wow [10:10:00.0000] nice work devsnek [10:10:11.0000] hehe [10:11:50.0000] that x++ one is really something [10:20:29.0000] ljharb: woohoo, thanks for merging https://github.com/tc39/ecma262/pull/2040 \o/ [10:20:52.0000] so fast [10:21:35.0000] ☚(ﾟヮﾟ☚) [10:21:41.0000] now i gotta remove the flag in engine262 [10:31:50.0000] ljharb: if i can't screenshare from linux can you share your screen, its just issue 1941 and pr 1948 [10:31:51.0000] huh, I didn't know there was a `"unit"` type [10:32:11.0000] devsnek: i'm on an ipad (－‸ლ) but i can try [10:32:16.0000] oh no [10:32:23.0000] we'll make it work [10:32:36.0000] someone's tea is going [10:32:46.0000] I was just gonna say that hahaha [10:33:10.0000] better make your cup before the water's gone [10:37:17.0000] yeah that water is totally gonna be gone [10:39:26.0000] ears gone [11:04:05.0000] shu: you said you prefer not to have "function get name() { … }", right? [11:04:52.0000] michaelficarra: ideally i prefer `get name() { ... }` [11:07:48.0000] +1 [11:21:07.0000] littledan / ystartsev: can you point me to something which explains the motivation for the callback argument to cleanupSome? [11:21:13.0000] it's a little weird to have "function" before "get name" :-) [11:21:46.0000] https://github.com/tc39/ecma262/pull/1948/commits/e417f396a276953c8329ddb89d8e523cf9cbe642 [11:21:57.0000] shu: michaelficarra: Bakkot: ^ [11:23:38.0000] Bakkot: do you mean the iterator or the per item callback? [11:26:02.0000] ystartsev the per-item callback [11:26:06.0000] that overrides the one the registry has [11:26:08.0000] that bit is weird to me [11:35:35.0000] Bakkot: These design discussions were mostly offline. I recommend you file an issue if you're skeptical of this design. [11:35:47.0000] I think someone found it to be more natural when writing code samples using it [11:35:50.0000] littledan mostly I just want to know what the motivation for it is [11:36:00.0000] will file if I remember after taking notes [11:36:07.0000] same motivation as using an iterator and returning a boolean [11:36:52.0000] hmm [11:37:05.0000] it's the "overriding the original callback" part which is the strangest to me [11:37:08.0000] "using an iterator and returning a boolean"? [11:37:14.0000] the fact that the registry's original callback isn't used anymore [11:37:18.0000] bakkot, we have some emails i can summarize [11:38:46.0000] jridgewell I always appreciate your presentations [11:38:53.0000] specifically I like the recaps [11:39:49.0000] recaps are important, everyone should take note [11:40:10.0000] 😀, thanks! [11:42:28.0000] can anyone contact the numeric separator folk (Sam Goto, Rick, Leo) to see if they can go next? [11:42:37.0000] leobalter ^ [11:42:45.0000] rwaldron ^ [11:45:50.0000] tc39 wg 3 js for build tools [11:46:03.0000] honestly wouldn't even be the most awful idea [11:46:48.0000] there's a tooling outreach call I think? [11:46:55.0000] which I keep meaning to attend and failing to for reasons [11:47:02.0000] i mean like, have a formal specification of js features for build tools [11:47:13.0000] like 402 is for internationalization [11:48:49.0000] actually i guess the embedded devices group is a better example [11:48:59.0000] devsnek: Decorators standardized in tools would still run into these constraints; we'd still have to decide which one(s) to violate [11:49:24.0000] littledan: well you don't have to polyfill it if its defined to be part of build tools [11:50:16.0000] I don't know whether all polyfill authors would agree with that. Anyway, we also heard from tools authors that they would prefer if transforms were per-file, without requiring cross-file knowledge [11:50:51.0000] its time for build tools to be cognizant of cross-file information [11:51:06.0000] tell me if my exported function isn't used anywhere else in the codebase [11:52:20.0000] p sure https://github.com/benmosher/eslint-plugin-import does that [11:53:26.0000] i have not observed it being able to do that [11:53:50.0000] might have it configured wrong though 🤷🏻 [11:54:46.0000] "Report modules without exports, or exports without matching import in another module (no-unused-modules)" [11:54:50.0000] claims to do that [11:55:02.0000] "unusedExports: if true, exports without any static usage within other modules are reported (defaults to false)" [11:55:10.0000] so you'd have to opt in [11:55:23.0000] if it doesn't do that, file me an issue [11:57:12.0000] It seems unusedExports is not well fit for library?? It's likely a library will not use all its exports? [11:57:38.0000] yup [11:57:48.0000] probably why it's off by default [11:57:49.0000] haxjs: which is why the rule allows you to explicitly configure your entry points [11:58:05.0000] for library usage, or for apps where the entry points are all bundler entry points [11:58:14.0000] (that are referenced in ERB templates, for example) [11:58:59.0000] Great, I will try it in my next project :) [12:03:36.0000] does anyone disagree with the claim that https://github.com/tc39/ecma262/pull/2106 already has consensus, based on yesterday's consensus on https://github.com/tc39/ecma262/pull/2057 ? [12:04:25.0000] yes; import.meta does not seem liek the same kind of thing as the Math and Reflect namespaces [12:04:36.0000] ok [12:04:39.0000] ljharb: I didn't realize we were talking about `import.meta` [12:04:47.0000] import.meta having a tostringtag seems wrong [12:04:53.0000] sounds good, i'll mark it as needs consensus [12:05:38.0000] littledan: https://github.com/tc39/ecma262/issues/1970#issuecomment-622248793 [12:05:53.0000] technically a host could do something weird [12:06:05.0000] like set import.meta.[[Prototype]] to something that already has a tostringtag [12:06:34.0000] littledan: i misconstrued your comment as agreement that import.meta should have it [12:06:43.0000] which comment? [12:07:07.0000] littledan: the one that says "+1 on new namespaces going forward", right after the one where i asked about import.meta [12:07:25.0000] import.meta being a namespace, since its properties matter but it itself doesn't [12:07:27.0000] why would we add it to import.meta [12:07:34.0000] it isn't a namespace like the others [12:07:38.0000] oh, sorry, I was responding to the original post [12:07:42.0000] it isn't something TC39 is going to populate [12:07:58.0000] bradleymeck: it might add something to it one day ¯\_(ツ)_/¯ [12:08:06.0000] but it's still a builtin object [12:08:09.0000] hallway track dead todya? [12:08:10.0000] ljharb: hosts can add any key [12:08:21.0000] ljharb: it isn't builtin, it is something a host supplies [12:08:36.0000] and there are many of them, so each having an own prop seems weird [12:08:46.0000] those are all reasonable concenrs [12:08:48.0000] *concerns [12:09:33.0000] hosts can supply their own toStringTag already it looks like (odd to allow setting symbols, but 🤷) [12:09:35.0000] if you could comment on the PR that'd be great; if it's not able to reach consensus we don't have to waste plenary time on it [12:13:55.0000] done [12:14:09.0000] thanks [13:01:15.0000] when is lunch over [13:01:26.0000] Now [13:02:21.0000] someone made a good point in the rust server about allowing multiple underscores in a row for padding binary literals [13:02:24.0000] sad we didn't get that [13:02:38.0000] can always be added later though [13:05:11.0000] what padding bin literal mean? [13:05:44.0000] haxjs: right now you can only use one underscore at a time [13:05:47.0000] `1__0` is a syntax error [13:05:49.0000] who is chewing [13:06:29.0000] I mean why 1__0 is useful? [13:06:35.0000] i have the same question [13:07:21.0000] though I don't think it's harmful :-) just don't get the use case. [13:07:38.0000] woo slice [13:07:39.0000] `1111_1111_1111_1111_1111_1111_1111_1111` [13:07:47.0000] that's only 32 bits [13:07:55.0000] imagine 64 bits [13:07:59.0000] rwaldron: please assign https://github.com/tc39/ecma262/pull/2043 to me once you've made all the planned updates [13:08:04.0000] devsnek that's only one _ at a time [13:08:15.0000] `1111_1111_1111_1111__1111_1111_1111_1111` [13:08:28.0000] two underscores helps [13:08:49.0000] ahh [13:08:54.0000] 1_________________________________________1 [13:08:56.0000] lol [13:08:57.0000] yeah makes sense [13:09:02.0000] ljharb sure will do. I think leobalter is actually going to tackle the fixes [13:09:06.0000] and at 64 you might have three in the middle [13:09:11.0000] two at each half way point [13:09:26.0000] one for each nibble [13:09:51.0000] not the end of the world obviously [13:12:06.0000] devsnek oh, sounds useful :) [13:13:21.0000] ljharb: strings do have @@slice [13:13:27.0000] in terms of this proposal [13:13:35.0000] devsnek: not according to the proposal's readme [13:13:39.0000] unless i missed it [13:13:43.0000] on twitter they did [13:13:59.0000] sathya explicitly said string is not included because it's unclear what slice means on strings [13:14:04.0000] devsnek: https://github.com/tc39/proposal-slice-notation#should-slice-notation-work-on-strings [13:14:17.0000] imo it's perfectly clear what it means on strings :-) [13:14:18.0000] oh that's unfortunate [13:14:29.0000] i'll get to that once the queue hits [13:14:57.0000] i'd rather argue about whether slicing strings should be utf16 or utf32 instead of whether strings should have slice [13:15:45.0000] strings already have slice, it's .slice. [13:16:08.0000] how we can make it slice on code point? [13:16:36.0000] make .slice work on code points [13:16:49.0000] ljharb: what [13:16:57.0000] i'm not saying that's possible nor proposing it [13:17:03.0000] that's an good idea, but it cause inconsitency between s[a:b] and s.slice(a,b)? [13:17:04.0000] but this is called "slice notation" so it should only do "what slice does" [13:17:17.0000] anyone regret making for-of a string iterate over code points? [13:17:25.0000] +1000 [13:17:33.0000] strings shouldn't be iterable, there should be a normal method for that [13:17:38.0000] nooo, it's by far the most useful choice [13:17:39.0000] bterlson: no [13:17:39.0000] like .keys/.values/.entries [13:17:40.0000] I think iterate over code points is good. [13:17:48.0000] code points isn't actually what people want, grapheme clusters is. [13:17:53.0000] speaking personally, I supported it but have since gotten zero value and have made mistakes [13:17:55.0000] keith_mi_: i think the first tack for that would be to see if we can replace more HTML collections with ObservableArray (which is what's motivating adding .item() to Arrays) [13:17:57.0000] code points is what people want [13:18:00.0000] code points are pretty much useless [13:18:02.0000] lol [13:18:03.0000] also, iterable strings interfered with flat/flatMap [13:18:04.0000] keith_mi_: if that's possible, then they should get @@slice for free, if this becomes a thing [13:18:15.0000] Bakkot: they want 💩 but they also want 🏳️‍🌈 [13:18:21.0000] code points doesn't give you both [13:18:21.0000] shu: is @@slice not the same as Array.prototype.slice? [13:18:23.0000] but yeah doesn't TabAtkins have an essay about this? [13:18:28.0000] keith_miller: it is [13:18:37.0000] ljharb: people don't want locale-dependent string iteration [13:18:39.0000] slice looks up .item? [13:18:51.0000] keith_miller: no no, i'm saying the tack to get HTML collections to have @@slice is to actually replace the bespoke HTML collections with ObservableArray, which inherits Array [13:18:54.0000] https://www.xanthir.com/b4wJ1 [13:18:56.0000] michaelficarra: i agree, but they *definitely* don't want to have to piece together grapheme clusters [13:19:01.0000] ohh, gotcha [13:19:11.0000] sounds good to me [13:19:19.0000] it should have just been String.prototype.codePoints to return an iterator [13:19:28.0000] shu: I like the ObservableArray thing anyway [13:19:32.0000] +1 [13:19:33.0000] so sounds good to me [13:19:44.0000] ljharb: I agree there's no one-size-fits-all default, so no default would've been best [13:19:51.0000] but if we HAD to have a default… code points [13:20:00.0000] perhaps. but we definitely didn't have to have one [13:20:10.0000] obv the ship has long since sailed :-) [13:20:58.0000] if code points were used everywhere then yeah, obviously indexing by code points is better than utf-16 units [13:21:05.0000] but having both in hindsight feels like a wrong choice :/ [13:21:17.0000] new string type [13:21:21.0000] like new bigint type [13:21:49.0000] yeah at least it will not split string at surrogate [13:22:59.0000] hypothesis: most uses of for-of string are bugged and assume a correspondence between iteration steps and string indexes [13:23:01.0000] devsnek yeah , i really hope we can have utf8 string which eliminate the need of many encoding/decoding [13:23:52.0000] most uses of for-of string are bugged --- how ? u can't get index in for-of, so how to make bug? [13:24:23.0000] this can't do more than slice, definitionally [13:24:42.0000] not sure how to argue for it beyond "I would use the crap out of it" [13:24:52.0000] ^ +1 [13:25:16.0000] original proposal have step, but seems removed now [13:25:37.0000] i would also use the crap out of it [13:25:47.0000] wait, are we assuming this will support negative indices? because if so, I don't think we can implement it as an iterator helper :( [13:25:50.0000] also, substr vs substring vs slice would all become this nice pretty syntax [13:25:57.0000] michaelficarra: yes, it supports negatives [13:26:06.0000] ystartsev: FWIW here's a list of languages with syntax: https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)#Slicing [13:26:07.0000] ljharb: that's unfortunate [13:26:22.0000] michaelficarra: it would throw i guess [13:26:25.0000] or yeah just not support it [13:26:28.0000] it has to, it's slice. [13:26:33.0000] That's probably not exhaustive though [13:26:35.0000] keith_miller: im not sure that "its in other languages" is the bar we want to use [13:26:56.0000] if its *all* of them though... [13:26:57.0000] definitely not a bar, but a strong indication that the syntax weight may be worth it [13:27:03.0000] what other bar is there then? [13:27:08.0000] I think it's a signal at least [13:27:10.0000] how do you determine if something is useful without it existing [13:27:20.0000] does elang have slice syntax [13:27:30.0000] drousso: we don't need any other languages to decide what's useful for JS. it's just massively helpful as a guide. [13:27:55.0000] oh sure i'm not saying "it's in other languages" should instantly mean "yes we should do it too" [13:27:58.0000] introducing new syntax means two things: syntax is more difficult for beginners to learn than names and it is more difficult to search. secondly -- this takes up syntax space which might be used for other thins [13:28:29.0000] in the cases of logical assignment, this aligned ??, ||, && with other binary operators [13:28:35.0000] I'm not sure this conflicts with any other syntactic space though, given that it's strictly within [] [13:28:35.0000] it made the language, in a way, more consistent [13:28:36.0000] i would argue that using this syntax for something else is possibly worse than the complexity of learning that it means slice [13:28:46.0000] ystartsev: in the case of slice notation, what else could it do that wouldn't be confusing for users of "most every other language"? [13:28:54.0000] ^ +1 [13:29:17.0000] i don't see consistency in other languages [13:29:19.0000] it's definitely harder to google for syntax tho, i agree with that one for sure [13:29:27.0000] they all have unique ways in which they slice [13:29:42.0000] ystartsev: sure but is there anything like this syntax in another language that doesn't slice in some form? [13:29:50.0000] there is some organization aroudn `[a...b]` [13:29:51.0000] FYI PureScript strings don't have any default iterability; all String operations have code point and UTF-16 code unit variants [13:30:09.0000] there's consistency in it being within [] though [13:30:09.0000] which is used for slice [13:30:12.0000] is Philip Chimento in here? he's up to present next [13:30:28.0000] i would be more open to this proposal, if it solved something [13:30:51.0000] i am confused by the random noises that start up, because presumably someone is manually unmuting [13:30:56.0000] but why, since there's a queue of speakers? [13:31:15.0000] can't jump the queue if you're muted [13:31:23.0000] yeah the biggest concern around this proposal is conflict with .item(), I think [13:31:27.0000] it does solve *something* - it solves the lack of ergonomics around the slice methods, and the lack of anything beyond "magic word: slice" as a protocol for other objects to participate in [13:31:31.0000] because negative indices are the selling point [13:31:37.0000] rkirsling: it doesn't conflict i don't think [13:31:43.0000] why it will conflict with item() ? [13:31:47.0000] oh because element vs. range [13:31:52.0000] rkirsling: right [13:31:54.0000] if anything they're complementary [13:31:57.0000] alright nevermind then [13:32:00.0000] shu: It's Brian when he unmutes to moderate [13:32:05.0000] ljharb: does `slice` have a lack of ergonomics? [13:32:13.0000] jridgewell: i see [13:32:13.0000] because i think this is debatable [13:32:37.0000] ystartsev: it's very debatable, as is anything around ergonomics, and it's fine that we ascribe different weights to that :-) [13:32:58.0000] i consider ergonomics to be quite important, but i am not convinced by the argument at the present moment [13:33:19.0000] it would be good to identify how we could identify sufficient demand then [13:33:33.0000] 'cause I don't think we'll be able to identify a "need" [13:34:50.0000] this seems like something where status quo is "fine" but this proposal would _feel_ a lot better [13:35:04.0000] so it's not solving a burning trash fire, but it's salving an irritant [13:35:18.0000] gsathya: part of my point is that the analogy to "other languages have slice notation" may be not as strong an argument as it sounds, because their slice notations weren't retrofitted, and thus are more symmetrical with their existing indexing notations [13:35:23.0000] yeah. that ended in kind of a sad way [13:35:37.0000] also echoing shu there, i think this is another argument [13:36:20.0000] that said i'm not anti this notation, i'm maybe weakly against but would be just fine with it being in the language [13:36:23.0000] shu, i'm not sure about that [13:36:37.0000] I agree with shu, a[-1] and a[-1:5] inconsistency is bad [13:37:00.0000] i'm sure a bunch of languages didn't ship their initial version with slicing syntax [13:37:34.0000] I remeber rbuckton suggest use ^1 instead of -1 :) [13:37:36.0000] fair enough, the high-order bit is whether there're points of inconsistencies and does it affect DX [13:38:01.0000] shu, how do i answer that? [13:38:17.0000] every second we don't have temporal is a second of pain [13:38:36.0000] devsnek: on which TimeZone? [13:38:45.0000] leobalter: mars time [13:38:48.0000] we need more feedback for temporal , it's now a really big proposal [13:38:49.0000] gsathya: hmm, i suspect the answer is "existing languages don't have this point of inconsistency". but maybe pick 3 popular languages that have slice syntax, and check if `n` in `[n:m]` is interpreted sorta-kinda the same as `[n]`? [13:38:56.0000] gsathya: python, rust, and something else? [13:39:35.0000] what does `n` in `[n:m]` is same as `[n]` mean? [13:39:53.0000] it mean a[-1] should work (but can't) [13:40:07.0000] yeah that seems to be the concrete barrier here [13:40:13.0000] given the domain of `n`, are all values in the domain interpreted the same in both notations wrt things like negatives, coercion [13:40:33.0000] so the only way to overcome it is introduce syntax like ^1 [13:41:13.0000] yeah, I guess you could disallow negative indexing in slice notation but now its no longer consistent with array.prototype.slice [13:41:36.0000] imo without negative indexing it's not worth the syntax weight [13:41:40.0000] yeah [13:41:47.0000] yeah that's kind of the key subfeature [13:41:53.0000] we could allow slice support ^1 if ^1 is sugar of new Index(1, {from:'end'}) [13:42:11.0000] `arr[-1]` may be counter intuitive in JS but I don't see it as a blocker for a richer feature such as `arr[-n:m]`. [13:42:11.0000] well, i would very much like it to be consistent with existing slice methods [13:43:43.0000] gsathya: i wanna be clear that i don't consider this inconsistency fatal, but an extra gotcha [13:43:58.0000] gsathya I think maybe we'd better first consider a[^1] ? [13:44:10.0000] that seems weird to me [13:44:15.0000] `[^1]` means "not 1" in git, and regex [13:44:21.0000] yeah I don't think I could support that [13:44:41.0000] sorry, in git it means "1 commit back" [13:45:23.0000] so, people were cool with the Temporal timeline? ystartsev and ljharb expressed concerns with that in the past; I think this timeline leaves plenty of time for review [13:45:23.0000] `^1` come from c# , but we could also consider other syntax [13:45:52.0000] littledan: they have given a timeframe within the realm of what i requested, so i am fine with it [13:46:58.0000] ljharb so ^1 seems ok as git usage? [13:47:04.0000] littledan: sorry, maybe i missed it; what timeline? [13:47:22.0000] shu, gotcha [13:47:32.0000] i'm pretty sure i'm going to need to see finalized spec text that has minimal further churn, for more than 2 months, to be able to properly review it [13:47:45.0000] iiuc we have till november? [13:48:24.0000] is the spec text settled? i feel like i've seen lots of changes still, recently [13:48:24.0000] yeah, I'm excited but it's basically a new spec [13:49:15.0000] what the diff of `if` vs `with`? [13:49:16.0000] (new spec as in "it's the size of 402", not as in "it's changed completely") [13:49:35.0000] haxjs: nothing, new term [13:49:51.0000] I prefer "if" over "assert" FWIW [13:50:24.0000] michaelficarra the example is ... if {type:json} with {...} [13:50:35.0000] `if` does kind of imply that if the condition isn't met, the import doesn't happen, when in fact it throws [13:50:41.0000] which is the semantics `assert` has already [13:50:59.0000] there's been some comments with that mistaken assumption on the repo already [13:51:06.0000] so `with` do not throw, only provide metadata? [13:51:24.0000] `with` isn't in the current proposal [13:51:44.0000] yeah the `with` also threw me when i readd this [13:51:47.0000] previously the proposal also allowed the possibility of "evaluators", ie, things that change what module you import [13:52:07.0000] but since it was restricted to conditions/assertions, changing `with` to `if` made more sense [13:55:57.0000] oh, `if` is a little bit strange, `assert` is a little bit clear. [13:56:39.0000] maybe `must {type:'json'}` :P [13:59:39.0000] thinking out loud: what about returning a Record/Tuple/primitive for JSON imports? [14:00:59.0000] would reduce __proto__ errors [14:01:07.0000] not bad. I like this idea! [14:01:50.0000] ah I see Mark M is on the queue with that point :) [14:01:51.0000] but it means we must first land record/tuple [14:02:51.0000] yep, that seems like the main objection, but maybe there's something strategic we can do, like saying record/tuple will be used only if available? [14:11:46.0000] is philip on irc? [14:12:12.0000] or i guess i can ping sffc: wdyt of contacting hebrew / arab communities? do we have contacts there? [14:12:16.0000] re: temporal [14:13:16.0000] ystartsev: I know some arab expats who are software engineers [14:21:53.0000] can someone give me an example of valid properties without quotes [14:22:16.0000] i'm confused and i went through the slides again and did not feel any less confused [14:22:40.0000] akirose: { type: "json" } vs. { "type": "json" } [14:24:18.0000] ohhhhhh lolol right [14:24:45.0000] assert { "\0": "YOLO" } [14:28:00.0000] can someone record the consensus in the notes for import conditions? [14:29:45.0000] littledan ^ [14:35:08.0000] rricard ^ [14:38:26.0000] anyone looking to get a stream of explainations or ask questions can join #tc39-beginners [14:39:16.0000] sorry about that ljharb, I will let dan properly record it [14:40:05.0000] ljharb: Draft conclusion at https://docs.google.com/document/d/1IHoLaRSH41oU4an4HwfngP8aASTM51HYzlWgEhjGyI0/edit#bookmark=id.3zje6vza7bnl please review [14:40:31.0000] thanks, sgtm - please lmk when there's a repo URL for json modules [14:41:10.0000] will do [14:44:09.0000] Whoever's running the meeting, could you approve me joining via phone? [14:44:24.0000] Probably an (832) number. [14:45:47.0000] ooh `item` has appeared [14:46:29.0000] I take no credit nor blame for Shu's slides [14:46:30.0000] good lord [14:47:40.0000] Note: not inherit, a Proxy around Array. [14:49:58.0000] mmm negative indices [14:50:21.0000] should i add a queue item asking if `.item` should go on strings [14:50:56.0000] is there a good way we can express support for proposals without unmuting and taking the floor etc.? [14:51:39.0000] benjamn: I too wish for that [14:52:13.0000] benjamn: you can put a queue item that's like "+1 part of what I have recorded in the conclusion of the import conditions topic is, "Split JSON modules into a separate Stage 2 proposal". Does this match everyone's understanding of the conclusion, or would we need another committee proposal for consensus to really make JSON modules at Stage 2? [14:52:31.0000] i'm sure we could come up with a convention for things where it's "read the queue item, move along" [14:52:39.0000] littledan: that matches my understanding [14:54:34.0000] ljharb: READONLY? [14:54:43.0000] sgtm [14:55:10.0000] i'll save my bikeshed energy for actual proposals, pick any word you like :-p [14:55:35.0000] haha sure, I hear that [14:55:41.0000] oops i clicked the wrong button [14:55:43.0000] hung up on the call [14:55:45.0000] ljharb: what was the question? [14:55:45.0000] node 14.6.0 is OUT [14:55:48.0000] WEAK REFS ARE LIVE [14:56:02.0000] * might be live [14:56:07.0000] shu: "what stuff is still open for stage 3?" and tab said basically only the clamping question [14:56:07.0000] lmao [14:56:13.0000] ljharb: yeah that sounds right [14:56:18.0000] cool [14:56:38.0000] getify raised some good points about "providing numbers larger than the length" and i think it's worth serious consideration [14:56:51.0000] ljharb: oh? link? [14:56:58.0000] shu: it's an issue on the repo, one sec [14:57:01.0000] ah [14:57:41.0000] shu: https://github.com/tc39/proposal-array-last/issues/21 might be it [14:58:29.0000] oh no wait, wrong proposal [14:58:51.0000] shu: https://github.com/tabatkins/proposal-item-method/issues/6 [14:59:01.0000] shu: the discussions have wandered around a bunch [14:59:12.0000] Yeah I'm really confident in rejecting that, at least as an issue against this proposal. There is no way we can have the function throw or return a new truthy value for oob access. [14:59:24.0000] it seems reasonable to me for `.item` to accept any negatives but only to accept positives up to the length - 1 [14:59:36.0000] that's the open question i had [14:59:46.0000] Hm, can you expand on that? I don't see the cases being at all distinct. [14:59:46.0000] (i'm very -1 on a sentinel value ofc, and also throwing) [14:59:57.0000] TabAtkins: yeah maybe issue 6 wasn't relevant, my bad if so [15:00:09.0000] ljharb: yeah undefined being conflated with "empty" is a ship that has sailed [15:00:10.0000] bbl, mtg [15:00:18.0000] agreed [15:00:27.0000] it's like a big ship that has sailed too, like a carrier [15:00:40.0000] hm, let me look harder for where the overflow question came up [15:00:53.0000] it's particularly relevant for empty arrays tho, i think? [15:01:07.0000] altho `[].item(n)` would just return undefined for any n, i guess [15:01:32.0000] that's what I would expect though [15:03:10.0000] ljharb: ystartsev The timeline for Temporal that I was talking about is in https://pipobscure.dev/slides/temporal-2020-07/#5 . This is designed to give everyone enough time to review and iterate, based on the concerns expressed last meeting. Do you have any thoughts on it? [15:05:56.0000] littledan: "now til november" is plenty of time iff the spec is largely finalized. has that happened? because i feel like i'm still seeing discussions bandying about major changes [15:06:25.0000] did you see the bullet point, "Finalize specification and pass to reviewers by September" ? [15:06:33.0000] ahhh ok, missed that, sorry [15:06:43.0000] september to november feels like a very tight window to me [15:06:59.0000] temporal feels like one of the largest proposals ever to land [15:07:05.0000] but i will certainly try [15:07:08.0000] IMO two months is a lot of review time. We usually use two weeks to ten days as the standard [15:07:45.0000] it's true that it's a big proposal, so I think it's justified to increase from 10 days to two months [15:08:00.0000] there's also a ton of context and concepts to page in [15:08:01.0000] maybe we can also recruit more than two reviewers and figure out good ways to split things up [15:08:33.0000] yes, that's true. I'm really happy about the proposal's documentation, so I hope that helps the review. [15:08:48.0000] how easily can the docs be dumped into mdn [15:09:07.0000] devsnek: That was a sorta-kinda design goal for these docs, but we'll see [15:09:18.0000] exciting [15:09:18.0000] devsnek: The WeakRefs docs got dumped into MDN and that seems to have worked out well [15:09:41.0000] nice [15:41:49.0000] benjamn: would you assume that even if https://github.com/facebook/regenerator/blob/master/packages/regenerator-runtime/runtime.js#L389 is fixed, it will remain present on the web for a very long time? (https://bugzilla.mozilla.org/show_bug.cgi?id=1644581 for context) [15:48:28.0000] ljharb: I'm actually somewhat optimistic that people update regenerator-runtime fairly often [15:48:46.0000] it would be a different story if it was transpiled code, but it's just a runtime library [15:49:00.0000] how quickly do you think that kind of fix could get in, to conditionally define toStringTag values? [15:51:03.0000] ljharb: in my mind this is a backwards-compatible change, so any new patch version I release will be compatible with https://github.com/babel/babel/blob/2bf38fb9149eb514a13bb608e5a9a0c06ad5cacd/packages/babel-runtime/package.json#L17 [15:51:13.0000] in other words, very quickly [15:51:30.0000] are you opposed to just using Object.defineProperty, to avoid the conditional? could do both obviously [15:51:50.0000] re: the last couple of comments in the bugzilla thread [15:51:50.0000] depends on your targets; if you use dP then it can't work in IE < 9, which might be a breaking change [15:52:07.0000] but also the define is unnecessary when there's already a toStringTag value [15:52:11.0000] so the conditional seemed simpler to me [15:52:36.0000] (the specific string isn't really important, just that there is one) [15:52:50.0000] ah yes, and Regenerator is increasingly only needed for older IE versions, so I guess that's still an essential audience [15:53:28.0000] realistically you could even do `if (!(toStringTag in whatever)) { whatever[toStringTag] = blah }` (don't have the code in front of me) [15:53:34.0000] that way it's only set where it's absent [15:53:49.0000] (probably tons of ways that could be worded ofc) [15:55:04.0000] ljharb: interestingly, when these toString tags were added, one of them was conditional and the other wasn't: https://github.com/facebook/regenerator/commit/28621286a46c95e2cde2970918b565545fcf5cdf [15:55:46.0000] 1 out of 3 ain't bad [15:56:01.0000] do you want a PR, or is it easier for you to do it? [15:56:02.0000] I'm imagining they should all be conditional? [15:56:08.0000] yes [15:56:28.0000] a quick PR would be great, so I don't have to self-review [15:56:31.0000] sure [15:57:36.0000] ljharb: although there already appears to be one? https://github.com/facebook/regenerator/pull/399 [15:58:07.0000] haha k, exe beat me to it [15:58:12.0000] i'll make the alternative [15:58:39.0000] that one uses defineProperty. [15:59:42.0000] ++ [16:00:14.0000] benjamn: https://github.com/facebook/regenerator/pull/400 [16:00:26.0000] i did it on the web ui, so lmk if i need to clone it and flesh anything out [16:01:18.0000] no worries, I'll make any tweaks necessary [16:01:34.0000] word, thanks [16:02:10.0000] tfw the polyfill breaks the actual feature [16:02:38.0000] not the first time this author's polyfill code has done that :-( [16:02:48.0000] yep, definitely a sad moment for any polyfill [16:03:13.0000] i don't *think* any of mine have had this problem yet, but i'm sure the second i post this, it's gonna happen [16:04:39.0000] this is why instead of writing polyfills you should just use a separate js engine [16:05:28.0000] ironically transpiling engine252 would involve regenerator [16:06:16.0000] does that have 10 fewer features than what's in JS [16:06:28.0000] fascinatingly (to me), the Rust Babel clone actually went to the trouble of converting Regenerator to Rust: https://github.com/swc-project/swc [16:06:28.0000] i'm going to start telling people it's called ecma262 because there are 262 features [16:06:50.0000] https://github.com/swc-project/swc/pull/554 [16:07:31.0000] I've never even heard of this [16:07:53.0000] I did at one point write my own regenerator though [16:08:14.0000] that might be when I first became interested in compilers [16:12:00.0000] wow this parser code is rough [16:27:14.0000] devsnek: yeah I can't vouch for swc from personal use, but it does seem to have users [16:30:57.0000] and it's ~fast~ [16:36:26.0000] ljharb: ok theoretically new installs of regenerator-runtime (or babel-runtime) will now have this fix! (regenerator-runtime⊙0 has been published to npm) [16:53:30.0000] awesome, thanks - hopefully the affected sites upgrade quickly 2020-07-22 [08:05:43.0000] whoever is managing the schedule, the function tostring item is ready to be rescheduled for whenever works [10:03:47.0000] quick reminder, we have #t39-beginners and i am doing descriptions of ongoing topics with a goal of explaining as much as possible [10:23:55.0000] ystartsev: you should announce that in #tc39 too! [10:25:24.0000] I believe a different chat tool would be easier to handle multiple channels but IRC is not helpful as it does not show the many options. [10:26:27.0000] I don't have anything against more channels, but I believe it will eventually be very hard to find, even more for beginners. All because IRC [10:27:16.0000] leobalter: we can add a section to the reflector (and maybe to the introductory email) listing out all the channels perhaps? [10:28:09.0000] <3 for changing away from upsert [10:28:18.0000] I say this because I 100% agree with the issue you point out, but the whole debate to change chat platforms is extremely bikeshed-dy. [10:28:33.0000] (and might take forever) [10:28:41.0000] ryzokuken: it's remains counterintuitive. It's a different tool and land. Even worse if you consider beginners might not have access to the reflector (yet?) or are not used to it [10:28:58.0000] even if "emplace" is different from the C++ meaning, I'm just excited that it's a real word [10:29:50.0000] I don't see IRC as ideal for our chat, I'm not a big fan of any chat tool, but fragmentation of multiple channels without a good handling might have negative effects. [10:30:05.0000] it's unfortunate, because it's not at anyone's fault [10:30:37.0000] again, while I 100% agree, I think it would take quite a lot of back and forth discussion to actually choose an alternative and make the switch. [10:30:59.0000] oh, I see TC39 trying a new chat tool since I started participating [10:32:04.0000] I know I also don't want Slack, but I'd personally like discord. I believe it would be very hard to have consensus. [10:35:30.0000] ftr i abhor discord and love slack, so i agree it's a hard thing to solve [10:36:29.0000] i have a js discord server. its mostly full of noobs asking about discord.js but it could in theory host other discussions as well [10:51:44.0000] Can we mute Brian please? [10:51:52.0000] bterlson: can you mute? [10:51:54.0000] bterlson ^ [10:56:30.0000] does anyone else hear "in-place" every time someone says "emplace"? [10:56:32.0000] Someone kicked me from the meeting. [10:57:20.0000] jridgewell: i kicked you on purpose. kind of. I kicked the "Unknown User" [10:57:20.0000] i agree with waldemar on emplace, we really should not name this emplace [10:58:06.0000] I don't know how to set my name on the iPad app [10:58:10.0000] i have it set in Teams [10:59:07.0000] IIRC emplace does mean a slightly different thing in C++ [10:59:16.0000] ... perhaps more than slightly actually [11:00:16.0000] jridgewell: i set it in the ipad app when clicking the teams link, before clicking "sign in as guest" [11:00:20.0000] shu: +1 [11:01:11.0000] I will say that, for CSS purposes, .getDefault() will *not* help me, but update() will. [11:01:18.0000] (Properties always exist on the property maps.) [11:01:40.0000] Ahh, signing up for Teams was a mistake then. [11:01:45.0000] yay ty jridgewell !! [11:01:47.0000] Will try again as a guest [11:07:24.0000] Oh, hm, calling `this.update()` from the insert() is an interesting case for the handler pattern. [11:09:42.0000] What's bradley's irc nick? [11:09:49.0000] bradleymeck [11:10:11.0000] Ah, skipped that because their last name is Farias. [11:10:39.0000] bradleymeck: Yo, on review I see you *do* have a section in the proposal explicitly for "update only", I just missed it on my first quick read, sorry about that. [11:10:58.0000] k [11:14:00.0000] ljharb: Iterable is definitely a noun? An iterable, as distinct from an iterator? [11:14:46.0000] iterable is any object with Symbol.iterator [11:14:57.0000] it doesn't prescribe a behaviour beyond that [11:15:02.0000] "An iterable isn't a noun" 🤔 [11:15:10.0000] this is the same issue we had with iterator helpers [11:15:16.0000] arguing about whether they should be iterable helpers [11:17:22.0000] bterlson: as a noun, you're right. but it really means "it's one of the things that are iterable" [11:17:51.0000] An iterator is the same story isn't it? [11:18:22.0000] i suppose that's true, but the iterator helpers proposal makes a canonical Iterator [11:18:28.0000] and that's what i'd expect Number.range to return [11:19:17.0000] ^ I wouldn't expect that. I would expect what MM expects, that the return of `Number.range()` could be iterated multiple times [11:19:45.0000] rickbutton: the return of .keys/values/entries on arrays/maps/sets, and .matchAll, can't be [11:19:52.0000] and neither can the iterator produced by a userland generator [11:20:04.0000] iow, "can iterate multiple times" is an expectation that will already bite you in a ton of places [11:20:50.0000] that's true, but I guess I'm using the mental model of a concrete `Range` object that is safe to iterate many times, the same way you can iterate an `Array` many times [11:21:25.0000] I like devsnek's reasoning. [11:21:29.0000] +1 [11:21:36.0000] If it's a constructor, then it should be an iterable [11:21:41.0000] agreed [11:21:43.0000] If it's a function, it should be an iterator [11:21:53.0000] like, in a language without iterators, I would assume `Number.range(a,b)` would return an `Array` with values from a->b [11:22:05.0000] rickbutton: as would i. but this language has them [11:22:08.0000] I'm also mildly in favor of `range(n)` == `range(0,n)` - I won't die if it's not there, but it's useful and clear. [11:22:12.0000] it's the same reason matchAll didn't return an array [11:22:35.0000] jridgewell: +1, yeah, if it's an iterator we *have* to go all the way to a class, or else the design feels incoherent [11:22:40.0000] I agree with function vs constructor => iterator vs iterable [11:22:42.0000] UGH *iterable [11:22:53.0000] (as a design pattern) [11:22:57.0000] yup [11:24:04.0000] So I think we need to look at the call pattern. [11:24:06.0000] i also think sticking a function on the front is good from the perspective of being clear about when you're reusing something [11:24:29.0000] It's used as `range(…)`, not `new Range(…)` [11:24:34.0000] ^ [11:25:57.0000] agree with "big missing piece" [11:28:12.0000] Strong +1 to Waldemar's upcoming question about start==end with inclusive; it should return the value once. [11:29:57.0000] I use range() a lot in Python, and I *have absolutey no idea* whether it's reusable or not. I have literally never once stored a range in a variable. [11:30:52.0000] ^ ditto 😅 [11:30:54.0000] same [11:31:09.0000] i think that observation is the key one [11:31:26.0000] tab's, that is. the reusability sticking point is a red herring in practice [11:31:42.0000] i tried to note in the issue that it almost never happens [11:31:46.0000] because people treat them as logic [11:31:48.0000] not data [11:32:46.0000] Wait that's a lie, I'm looking at a line where I do store a range in a variable (so I can manually increment it in the following loop), but it's not reused. [11:33:00.0000] wow [11:33:14.0000] i'm sorry for disappointing you, devsnek [11:33:46.0000] TabAtkins: would it be prohibitive to stick it in a function if you needed that in JS? [11:34:03.0000] absolutely not, i think "wrap it in a function" is completely reasonable here [11:34:18.0000] wsdferdksl: Can you open an issue for your queue item [11:34:34.0000] I think it should be addressed [11:34:41.0000] hax is the only person i know that isn't on board with "wrap it in a function" [11:35:03.0000] sorry to be a time stickler friends, but we're over time. Reminder to pick conservative timeboxes if you definitely want your proposal to advance 😀 [11:35:08.0000] actually maybe mark as well [11:35:10.0000] couldn't tell [11:37:52.0000] Hmm. Yeah, these operators just avoid `Promise` and `()`. That's minor, but also, I can easily see it actually being mildly significant in a codebase that's heavily async. [11:38:51.0000] ljharb: stack traces in v8 already have nice stuff for Promise.all [11:38:53.0000] if they always use the built-in promise operations there's probably some performance implications as well [11:39:00.0000] it will tell you which index the error came from [11:39:03.0000] yeah I think it's pretty cool but syntax is soooo expensive, I don't know if this is one of those things we need to push on language learners [11:39:20.0000] Bakkot: it'd be cool to see those numbers [11:40:07.0000] devsnek: that is nice [11:40:11.0000] michaelficarra: Bakkot: my intuition here is that the performance cost promise combinators is not the synchronous logic of the combinator [11:40:19.0000] people *really* like using the shiny await syntax [11:40:20.0000] speeding that up probably won't help [11:40:26.0000] michaelficarra: On the other hand, idents/property access I think is the lightest possible syntax addition? Readable and even searchable, unlike grawlix operators. [11:40:36.0000] and by having to use Promise.all to gain concurrency, a lot of code is unnecessarily sequential [11:40:51.0000] providing await syntax for it would go a long way imo to improve that [11:40:57.0000] ljharb: i don't understand that point, how does this add new concurrency? [11:41:38.0000] I am also not sure on that point [11:41:38.0000] what would be more interesting is for-await-concurrent [11:41:48.0000] sure, but that's a different proposal [11:41:54.0000] shu: `await.all x` over `await Promise.all(x)` is identically concurrent [11:42:20.0000] ljharb: you said "a lot of code is unnecessarily sequential", implying new syntax will make them... concurrent? [11:42:22.0000] shu: i'm saying that people are more likely to *use* Promise.all semantics if there's syntax for it, because they *really* like using `await` and are under the misimpression that they don't have to use Promise things when using it [11:42:56.0000] shu: i'm saying there's a lot of places people are doing `await x; await y;` where they could do `await.all [x, y]` instead (or `await Promise.all([x, y])` instead), and they're more likely to do that change if it's got syntax [11:43:23.0000] the current scenario is that `await` is an attractive nuisance *because* it makes it too easy to avoid properly using `Promise.all` [11:43:35.0000] ljharb: Agree, I think the syntax affordance, while *relatively* minor, can easily have outsized effects on actual usage. [11:43:56.0000] hm, okay, that's an interesting point [11:44:00.0000] that dan's making now i guess [11:44:39.0000] `await.all ArrayLiteral` doesn't feel right to me yet [11:44:42.0000] but i like the general idea [11:45:07.0000] I mean, [] is the only way to invoke an n-ary operator, I guess. [11:46:00.0000] fwiw, I suspect the "use original value but accidentally call into customizable stuff" is accidental - it probably *wants* to just use purely original stuff, like `await` does. (And I think it should do that.) [11:46:41.0000] we could make `await.all (a, b)` work, but I don't seem much reason to [11:46:48.0000] the array literal is more orthogonal [11:46:59.0000] i'm imagining some sort of block thing [11:47:05.0000] but i don't have it worked out yet [11:47:53.0000] Yeah, given that Promise.all() takes an array, having the syntax take n-ary args instead would be a very bad thing [11:48:11.0000] just say no to varargs [11:49:24.0000] i still don't feel convinced that await.all significantly improves discoverability [11:49:25.0000] Sigh, if only we had named args... [11:49:32.0000] that's what the argument comes down to, right? [11:49:36.0000] TabAtkins: we do! [11:49:42.0000] that folks using await are simply unaware that it's promises under the hood [11:49:51.0000] ^ +1 [11:50:02.0000] shu: I don't understand what you're saying. [11:50:14.0000] the assumption is that they don't know about promises [11:50:14.0000] shu: yes [11:50:16.0000] but know about await [11:50:18.0000] shu: that is accurate [11:50:22.0000] yeah I would rather educate [11:50:44.0000] TabAtkins: the argument put forth by dan and jordan is that today, because devs know about async/await and _only_ know about async/await, they never learn it's all Promises under the hood [11:50:50.0000] i tell about 30 people a week on irc, every week for 5 years now, that `async`/`await` is not a replacement for promises, and that they still need to understand promises to use it properly. [11:50:51.0000] "dont' know about promises" is not equal to "reaches for linear awaits rather than Promise.all(), by default"; the latter is the arg here. [11:50:52.0000] I don't think this is necessarily more obvious, because it's syntax that no one would expect to exist [11:51:11.0000] it's not that they'll discover it [11:51:16.0000] it's that they can be told to use it, via review or a linter [11:51:24.0000] TabAtkins: why do they reach for the linear awaits rather than Promise.all if they are aware of promises? [11:51:24.0000] fair [11:51:27.0000] It really is just easier to type `await p1; await p2;` than `await Promise.all([p1, p2]);` [11:51:51.0000] shu: because most people don't seem to understand that promises are like a dependency graph, and that you should only await something when there's no additional work to kick off [11:51:53.0000] ljharb: on that note I had somebody talk about hitting no-return-await this morning and it was somebody I definitely thought should have known [11:51:58.0000] yep [11:52:11.0000] Without counting chars I can't tell if *three* promises in a row is shorter or longer than P.all(), but it's still *easier* to type - in particular, no `([...])` to type, which is slightly tricky. [11:52:20.0000] i mean, eslint even has a `require-await` rule, which is totally nonsensical, because the eslint maintainers didn't seem to understand async/await properly at the time. [11:52:53.0000] are people just as likely to write their promise chains needlessly flat [11:53:15.0000] heck, i see code all the time like `async function foo(promise) { let result = await promise; return result; }` [11:53:21.0000] with promises, i find people are more likely to write things as separate variables than in a single long chain (which is what an async function full of `await`s is) [11:53:43.0000] yup, same intuition here. [11:53:45.0000] https://es.discourse.group/t/array-prototype-uniqby/138 [11:54:24.0000] ljharb: TabAtkins: thanks [11:56:59.0000] This slope really isn't that slippery. [11:57:52.0000] I'm sorry I don't endorse hating on programming languages but i really do hate that about teaching/learning Ruby [11:58:39.0000] what was the note about ruby [11:58:47.0000] to be fair you could probably make filterMap much faster than filter + map [11:59:03.0000] since you don't have to iterate the array twice [11:59:14.0000] (I just had a WG discussion earlier today about adding more numeric constants to CSS (we already have e and pi); dealing with slippery-slope is a basic requirement of language design, not something we can or should ever be absolute about.) [11:59:25.0000] `flatMap`? [11:59:35.0000] Yeah, filterMap() is actually specifically an example I'd use as something to *add* ^_^ [11:59:51.0000] devsnek: there's a method for everything [12:00:02.0000] does that mean we now need to do combinatorics of every prototype method? [12:00:03.0000] jridgewell flatMap is a single operation for people coming from a fp background; I don't think that's true of filterMap etc [12:00:10.0000] `filterMap` and `mapFilter`? [12:00:15.0000] then again there are all kinds of weird performance pathologies in the std library design I tell people fix on their own [12:00:22.0000] Who would you differentiate between "remove this" and "false"? [12:00:37.0000] how** [12:00:41.0000] jridgewell: sentinel value provided to the callback [12:00:41.0000] My favorite is that i tell everyone to relpace all the typed array methods with a per type one [12:01:08.0000] Because you don't get hit with the polymorphism perf hit [12:01:26.0000] drousso: "if we do X, doesn't that mean we'd have to do combinations(X)" is precisely the argument I was just saying isn't a valid argument here; applying judgement here on where the line is is already a basic part of language design. [12:01:39.0000] oh yeah no i agree [12:01:43.0000] keith_miller: pre-fused methods seems fine to me tbh if they're common enough [12:02:25.0000] i should've been clearer i was being more of a "devils advocate to prove the problem" 😅 [12:02:34.0000] this reminds me of how Dart's standard library has .splitMapJoin() [12:03:46.0000] ljharb: stepping back a conversation, what about having the linter complain about `await p1; await p2;` in current code? [12:03:52.0000] drousso: Right, it's just never a useful objection to bring up at all, imo. "If we add this, what else hits the same line? Is it a lot? Are we okay with that?" is reasonable, but usually instead it's presented as an ipso facto rejection. [12:04:30.0000] i do think there is a very valid argument for "if this passes muster, what are the criteria for other things passing that muster" [12:04:43.0000] btw, i'm signing off the meeting for the rest of the afternoon, got prep work for CSS f2f next week. (I'll still be in chat, just saying I won't be in convos.) [12:04:57.0000] I do agree that "if we do X then we need to combinations(X)" is not helpful [12:04:57.0000] drousso: Right. Say that, instead, and I'll be happy. ^_^ [12:05:06.0000] fair [12:05:57.0000] (Basically I've become very wary and alert, after twelve years of standards work, for fully-general counterarguments. If you apply the argument to virtually any topic with no change, it's not an argument, it's stop energy.) [12:06:21.0000] *if you can apply [12:08:51.0000] ljharb: i'd still love to see some examples of people unwittingly serial awaiting where there is no inherent serialization required [12:09:15.0000] oh that should be very easy to find [12:09:29.0000] my experience is that serialization is rarely wrong, and that may be another reason why it's reached for by default [12:09:53.0000] whereas you usually have to do a lot more thinking to make things parallel [12:10:17.0000] almost by definition, serializing is almost never *wrong* compared with Promise.all() [12:10:38.0000] well, precisely [12:12:38.0000] this DX argument talks about an affordance so Promise combinators are easier to reach for, and if inadvertent incorrectness is a factor, that should affect the argument [12:12:44.0000] bbl lunch [12:13:23.0000] rkirsling: sometimes that's actually desired tho [12:14:44.0000] shu: i see lots of things like `const a = await getA(); const b = await getB(); const c = await getC(B);` which should be `const [a, b] = await Promise.all([getA(), getB()]); const c = await getC(B);` (and even that's unnecessarily serial if what follows the `c` declaration doesn't actually require a, b, or c) [12:14:59.0000] iow, i'd say serialization is wrong if it's not necessary [12:15:58.0000] fwiw I almost never encounter this; glancing around my codebases it's all very linear data dependencies, at least within an individual function [12:16:28.0000] i'm sure it varies by codebase domain, and individual programmer mindset [12:17:09.0000] but i'm often writing code where i have to make multiple async requests for data, but they can be intermixed in ways that increase concurrency. [12:17:38.0000] like, 2 requests require no input, 2 requests require input from 1 of the first one, and a final request requires 3 of the 4 results, or something [12:18:55.0000] how about a native api for limiting concurrency [12:19:04.0000] i guess that's an option for Promise.all [12:19:28.0000] Isn't that just what the combinators/chaining already are? [12:19:32.0000] not really for Promise.all [12:19:55.0000] Prome.all takes a set of promises for results which are already being computed [12:19:57.0000] oh right no since you pass the already existing promises to promise.all [12:20:11.0000] so yeah concurrent scheduling api [12:20:27.0000] class Promise.Queue [12:21:07.0000] Right. What I mean is, Promise.all() is already "everything's concurrent" and Promise#then() is already "these two are serial". So all the tools are already there. A more ergonomic API for setting up a dag out of promises might be reasonable, tho. [12:22:14.0000] out of async functions, not promises [12:22:16.0000] TabAtkins: its more like saying, only have 4 http requests going at once [12:22:30.0000] you'd set up a queue that schedules when the async functions are called [12:23:19.0000] Ah, ok, yeah that's a useful thing (tho I think beyond the scope of this discussion?) [12:23:29.0000] yeah it is [12:23:36.0000] i just momentarily messed up the abstraction in my head [12:23:41.0000] re saying it was an option for promise.all [12:23:48.0000] Bakkot: Oh, getting async function composition, hm. [12:25:42.0000] Like, the problem here is that the "best" way to handle async stuff is to *always* store async values in promise variables, and then *only* await them at the moment they're needed. If you do that, you can even do serial awaiting without a problem - you've already kicked off the operations, so serially awaiting the results is just fine (difference is just a few microtasks). [12:26:20.0000] But people dont' do that, they await the operation immediately because it lets them continue to think about their code in sync terms, which is totally reasonable - asynchrony is *hard*. [12:27:35.0000] So anything that makes it easier for people to reach for better asynchrony at the point of making async function calls is good, I think. `await.all` feels like it would help there, I think. (but i don't have strong feelings about it yet) [12:30:56.0000] (I was going to suggest that having an op that let you more easily treat a promise as its value at the point of use might help, but that's literally just `await` already. We just, uh, kinda screwed up the ergonomics of `await` from the get-go.) [12:44:45.0000] nah await is good [12:46:52.0000] i agree with tab, `await` is way too easy to misuse in my experience. [12:47:43.0000] await has *awful* ergonomics, because it's a low-precedence prefix operator. [12:48:03.0000] Can't mix it into a method chain without terribly awkward contortions, for instance. [12:48:17.0000] about await* -- I really don't like the * use in generators; it feels like a mistake to me. i wish we'd use spread instead. [12:48:19.0000] foo.bar().asyncaz() [12:48:31.0000] await ...arr [12:48:48.0000] `foo.bar().asyncBaz().qux()` is instead `(await foo.bar().asyncBaz()).qux()`, just awful [12:49:05.0000] I think Rust *slightly* screwed up their solution, but it's overall the right direction. [12:49:24.0000] hence pipeline I guess [12:49:35.0000] Pipeline does make it a bit easier, yeah [12:50:07.0000] Eh, scratch that, pipeline basically solves that problem, yeah. [12:50:36.0000] shu: your mic is enabled, if you didn't know [12:50:39.0000] TabAtkins: in fact, my advice to all newcomers is "start with no promise chains and no `await`s whatsoever. make a new variable for every `.then`/`.catch`. then, once everything's tested and working, refactor to use Promise.all _wherever possible_. then, make chains. and only *then*, use `await` in front of each chain [12:50:54.0000] ljharb: That's great advice, I wish everyone followed it. ^_^ [12:50:54.0000] rickbutton: i have a hardware mute [12:51:00.0000] +1 [12:51:27.0000] thank you [12:51:28.0000] I tell newcomers the exact opposite of that [12:52:03.0000] shu rickbutton on the hardware mute, Shush is a very nice app if you're on MacOS [12:52:10.0000] write it with sequential `await`s first so the logic is clear, refactor to use `Promise.all` afterwards only when you have a reason to [12:52:16.0000] premature optimization is the root of all evil [12:52:29.0000] nice, TIL leobalter [12:52:35.0000] more important to make the logic clear and correct [12:53:05.0000] "premature optimization *and* casual deoptimization are both pretty bad evils" is my feeling, honestly [12:55:17.0000] "yeah I deopt, but I like to keep it casual" [12:59:27.0000] ime the logic - which includes the implied dependency graph - is clearer to newcomers with promises [12:59:49.0000] but obv both of our positions are anecdotal and subjective [13:04:33.0000] this still doesn't support arbitrary compound keys though, since they can only contain value types [13:05:09.0000] it could if it didn't disallow objects [13:05:25.0000] although to be fair I think they have a solution to that by representing an object's identity [13:06:05.0000] i'm hoping we can at least get boxes [13:06:46.0000] i wouldn't consider symbol weakmap stuff to be the solution here [13:08:29.0000] i came in late did this state that the value is normalized to a +0 value or if they are just equal for ==/=== [13:08:40.0000] bradleymeck: pretty sure the latter [13:08:47.0000] bradleymeck: it consider -0 === +0 [13:08:52.0000] does not normalize [13:08:59.0000] it also considers NaN === NaN [13:11:17.0000] @wsdferdksl the earlier slide showed that order of entries in a record is *not* significant for equality [13:12:10.0000] for which reason Symbols are disallowed as record keys [13:24:33.0000] my computer just froze [13:24:35.0000] why are symbols as record keys not possible? [13:24:45.0000] Bakkot: i have comments ofc but i am restarting [13:24:48.0000] devsnek: that's my queue question - i think it's because there's no way to sort them. [13:24:55.0000] ljharb: what does "sort" mean [13:25:01.0000] devsnek: as in, sorting the keys [13:25:14.0000] why do keys need to be sorted [13:25:18.0000] so that `#{ a: 1, b: 2 }` and `#{ b: 2, a: 1 }` are equivalent [13:25:20.0000] https://github.com/tc39/proposal-record-tuple/issues/15#issuecomment-662135746 [13:25:32.0000] https://github.com/tc39/proposal-record-tuple/issues/15#issuecomment-662415531 [13:26:23.0000] the order of getOwnPropertySymbols seems very unmotivating [13:26:48.0000] "what the order is", surely. but "that it's consistent"? i think it's pretty important [13:26:53.0000] generally its just weird to me [13:26:54.0000] as in, you are OK with Object.is(a, b) being true but getOwnPropertySymbols(a) not being the same as getOwnPropertySymbols(b)? [13:26:57.0000] that the order has to be part of this [13:27:05.0000] like you shouldn't need to sort the non-symbol keys either [13:27:24.0000] Bakkot: yeah totally 100% [13:27:28.0000] same for Object.keys [13:27:37.0000] mm [13:27:38.0000] well [13:27:43.0000] that is an opinion one could hold [13:27:47.0000] lol [13:27:49.0000] devsnek: two records with different orders and the same keys shouldn't be distinguishable tho. [13:28:18.0000] are people determining identity by the order of keys on things? [13:28:27.0000] the other way around [13:28:38.0000] people assume that if a and b are the same, then then are indistinguishable [13:28:43.0000] this being what it means to be "the same" [13:28:46.0000] A is A [13:28:59.0000] it seems to me that they're the same even if the keys are in different orders [13:29:32.0000] i don't hold that intuition [13:29:35.0000] if they are distinguishable they are not that same [13:29:38.0000] *not the same [13:29:42.0000] things are the same only when every single aspect of them are identical [13:29:50.0000] otherwise they can only be similar, not the same [13:29:57.0000] an engine can have a stable sorting of symbols [13:30:04.0000] as littledan is explaining right now [13:30:47.0000] how would we specify that tho [13:30:48.0000] what is mark saying rn [13:30:56.0000] side channel through symbol keys? [13:30:56.0000] ljharb gloabl incrementing counter works fine [13:30:59.0000] without communicating "symbol creation time" [13:31:15.0000] we could put a counter on them [13:31:17.0000] like if i do `const a = Symbol(); const b = Symbol(); return [b, a]` you shouldn't be able to determine that i made `a` first [13:31:18.0000] agent.symbolcounter [13:31:19.0000] devsnek I believe the example is https://github.com/tc39/proposal-record-tuple/issues/15#issuecomment-662545733 [13:31:21.0000] my computer froze at a most inopportune [13:31:22.0000] time [13:31:32.0000] bakkot: what was said about implementer concerns? [13:31:47.0000] ah i see [13:31:54.0000] we had a similar concern to this as well [13:31:58.0000] Bakkot: in terms of implementation i was thinking of using the value's hash code to sort [13:31:59.0000] shu: I said I want implementation buy in before stage 3, ystartsev said they've been talking about it and are tentatively in favor, moddable said they're concerned [13:32:01.0000] the object/record issue [13:32:02.0000] "fatigue" is a very good word [13:32:21.0000] that wouldn't reveal their creation order [13:32:37.0000] Bakkot: okay thanks [13:32:42.0000] devsnek: how would two symbols with the same description have different hash codes, but not reveal creation order [13:32:50.0000] devsnek: and also not be random [13:32:54.0000] Bakkot: yep, we have been talking to them a lot and giving feedback. we aren't 100% "yes this should happen", but we do see the motivation and think its worth investing more time / giving it stage 2 (just to reiterate) [13:32:55.0000] devsnek it would probably reveal memory addresses, which is worse [13:32:59.0000] devsnek that's like an actual security issue [13:33:02.0000] hashes aren't memory addresses [13:33:10.0000] for objects with identity they frequently are [13:33:24.0000] if they're not deterministically based on observable traits, how could they not be [13:33:27.0000] iirc v8 chooses them from a pseudorandom number generator [13:33:38.0000] Bakkot: literally hashing the counter? [13:33:54.0000] or using a PRNG, another fair example [13:33:55.0000] michaelficarra hashing the counter would work, but if you have a counter, just use the counter, and then it's stable across engines too [13:34:11.0000] though I guess leaks the thing [13:34:32.0000] personally I kind of like random-but-stable ordering; I proposed it in the above issue I think [13:34:41.0000] maybe I proposed random-per-read [13:34:46.0000] found it https://source.chromium.org/chromium/chromium/src/+/master:v8/src/execution/isolate.cc;drc=0ee4438ca83448bca93cb11bc3012856d29303dd;l=3893 [13:35:07.0000] devsnek yeah they do that because of exactly the security issue I mention, I am pretty sure [13:35:12.0000] I reject Mark's claim that it necessarily leads to a communications channel [13:35:25.0000] if there was no ordering it would be a communication channel [13:35:34.0000] Is the "Equality semantics for `-0` and `NaN`"(https://github.com/tc39/proposal-record-tuple/issues/65) postponed to be decided at stage3 so it's not a concern to have consensus at this stage? It's been quite a hot debate (154 comments). [13:35:34.0000] devsnek but compare: https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#hashCode-- [13:35:47.0000] haxjs: afaict it's decided [13:35:47.0000] "This is typically implemented by converting the internal address of the object into an integer" [13:35:54.0000] Bakkot: lets not do what java does [13:35:57.0000] haxjs: SameValueZero, basically [13:35:59.0000] devsnek :P fair [13:36:15.0000] devsnek but that means we have to write something down which isn't "do whatever you want", is my point [13:36:22.0000] because the obvious whatever-you-want thing is memory address [13:36:47.0000] ljharb it is labeled as "undecided point" [13:36:53.0000] I think we should allow implementations to use the memory address if they want [13:37:05.0000] haxjs: ah. if it gets stage 2 with those semantics i would take that as decided [13:37:12.0000] Moddable may choose to use the memory address, for example [13:37:13.0000] haxjs: but i suppose it could change within stage 2 if needed [13:37:23.0000] Bakkot: "a unique number which is not correlated with the object's location in memory or when it was created" [13:37:24.0000] :P [13:37:44.0000] works for me tbh [13:37:58.0000] what is "memory" according to the spec [13:38:06.0000] spec does not have the concept [13:38:09.0000] this actual wording wouldn't work [13:38:18.0000] does atomics not talk about memory [13:38:19.0000] but we could find something like it [13:38:22.0000] devsnek nope [13:38:25.0000] well [13:38:26.0000] e [13:38:27.0000] it has a memory model [13:38:33.0000] but not in the sense which is relevant here [13:38:41.0000] we could definitely specify this [13:38:42.0000] is the point [13:38:44.0000] that V8 identity hash is very slightly biased to 1 [13:38:57.0000] /me whoever is anonymous wombat, you are doing an awesome job is taking note, my hands are burning! [13:39:08.0000] michaelficarra: report to h1 [13:39:10.0000] :^) [13:39:35.0000] i am not sure that we can _definitely_ spec "memory" writ large [13:40:04.0000] we can say that it shouldn't be correlated to when the object was created [13:40:14.0000] and leave security to implementors [13:40:38.0000] devsnek: +1 [13:40:53.0000] not all implementors have the same security model [13:40:55.0000] its my right to make a js engine that can be pwned [13:41:07.0000] normative note: must not allow pwnage [13:41:13.0000] it's your right to catch covid too i guess [13:41:14.0000] that depends on your system of morality [13:41:26.0000] this feels like tdz now [13:42:57.0000] michaelficarra / devsnek if you have a concrete way of specing symbols in records which wouldn't violate either the "Object.is implies indistinguishable" constraint or the "does not side channel symbol creation time" constraint, I think it would be worth opening on the issue tracker [13:43:07.0000] though it would probably be a followon proposal at this point [13:56:21.0000] brad4d: The reason symbols were disallowed was because there was no way to ever make a symbol "weak" if one can reconstruct it at will. [13:56:51.0000] can we stay on the current proposal, is that a point of order [13:57:03.0000] This led to the debate over whether we should disallow some symbols and no others, and after a while we decided to not allow any. [13:58:05.0000] s/no/not/ [13:58:16.0000] there has to be some sort of thing [13:58:21.0000] that fulfills being a nice api [13:58:24.0000] and the ses requirements [14:01:45.0000] oh man i would love if r&t could just hold objects [14:04:10.0000] you don't lose the performance of deeply immutable by it referencing an object do you? [14:04:31.0000] the benefit of deep immutable to performance is that you can safely pass it around without having copying [14:04:45.0000] if it holds an object that is no longer the case, and you have to defensively copy all records and tuples [14:04:56.0000] how is that the case [14:05:09.0000] which of those two things? [14:05:14.0000] the loss of no-copy [14:05:23.0000] uh [14:05:38.0000] the point of defensive copying is that you can hand it to someone you don't trust, and not worry about your data getting mangled [14:05:51.0000] if you hand them a pointer to a mutable thing you still want to use, you have to worry about that [14:06:04.0000] but if you put an unfrozen object in your record/tuple, aren't you already explicitly ok with that? [14:06:05.0000] even if the pointer is embedded in an immutable thing [14:06:13.0000] oh so you weren't answering the performance question [14:06:22.0000] I was answering the performacne question [14:06:34.0000] the performance benefit is, you don't have to defensive-copy to avoid this worry [14:06:46.0000] you still don't have to defensively copy the record [14:06:49.0000] its immutable [14:07:01.0000] if it holds an object, then you do have to [14:07:06.0000] (deeply) [14:07:18.0000] because handing it out gives you access to a mutable thing [14:07:18.0000] don't put the secure part in an object [14:07:34.0000] just because you can have an object in a record doesn't mean you have to [14:08:10.0000] yeah it just means you have to be defensive all the time, instead of being able to trust that records and tuples are safe to hand around [14:08:36.0000] i don't understand what you're defending against [14:08:41.0000] people forgetting that something is an object? [14:09:08.0000] you still have to defensively remember to use records [14:09:41.0000] if my API takes records, I can use them and hand them to other people without worrying about breaking my caller's guarantees [14:09:51.0000] if it takes records but records can hold objects, this is not the case [14:09:58.0000] that breaks the guarantee that you can pass an object [14:10:14.0000] my point being that there are a lot of tradeoffs here [14:10:26.0000] how does it break that guarantee? [14:10:46.0000] or like [14:10:50.0000] what guarantee are you talking about, I guess [14:10:59.0000] the ability to pass an object [14:11:17.0000] also why is it your api's problem if the caller passes a mutable structure [14:11:53.0000] I can take an object just fine I just have to deep-copy it first, which I do not have to do with records [14:12:04.0000] why do you have to deep copy it [14:12:12.0000] its the caller's object [14:12:17.0000] maybe they already deep copied it before giving it to you [14:12:23.0000] it is my API's problem if it mutates things its caller expects not to be mutated [14:12:28.0000] don't do that [14:12:38.0000] mutating an object you didn't create doesn't seem like a defensible practice [14:12:49.0000] right, the point is I am trying to avoid doing this [14:12:50.0000] and if it's a record you can't mutate it anyways [14:13:05.0000] right, the point is that I don't have to worry about it if it's a record [14:13:10.0000] that is the whole point [14:13:10.0000] i don't understand how ends up being mutated [14:13:17.0000] if you're not mutating it, you don't have to worry regardless [14:13:22.0000] and if you are, you can't take a record anyways [14:13:26.0000] i'm confused [14:13:31.0000] "oops i accidentally created a property on the value" i don't get how this would happen [14:13:52.0000] this happens if I am handing it off to other code [14:13:58.0000] sure, *that* code might mutate it [14:14:13.0000] the security of the object was not yours to begin with [14:14:13.0000] but similarly, it can't take a record if it's doing that [14:14:22.0000] it was whoever gave it to you [14:14:54.0000] devsnek that is a position one can take, but I am very glad that position is not widely held among library authors [14:14:56.0000] so to give it something and have it not mutate it, you already have to know if "it mutates" [14:15:12.0000] i mean, i don't *want* anything someone gives me to be mutated, even transitively [14:15:12.0000] ljharb if the other code takes a record, I don't have to know that! [14:15:20.0000] i would be very sad to know the only reason library authors aren't mutating things is because they *can't* [14:15:29.0000] ystartsev: Thanks for keeping the symbols as weakmap keys proposal honest on Stage 2 requirements. We need to do better about not deviating from the stage process. [14:15:37.0000] Bakkot: so you're saying, this relieves a code auditing burden of your deps? [14:15:42.0000] ljharb if the other code takes a record, I can trust that it is not going to accidentally mutate stuff, without checking its implementation [14:15:44.0000] yes [14:15:45.0000] could we give object in record/tuple a special syntax to avoid such problem? [14:15:48.0000] no one audits their deps [14:15:58.0000] i still don't get the whole "accidentally mutate" thing [14:16:01.0000] Bakkot: i do :-p but i'm not confused now, thanks [14:16:41.0000] ljharb I have seen you contribute to projects for which I am 100% confident you have not read all the code in the transitive dependency graph of the project [14:17:09.0000] probably doesn't have security concerns about those projects? [14:17:20.0000] it's not a security concern [14:17:23.0000] it's a correctness concern [14:17:26.0000] you said it was a security concern [14:17:29.0000] I did not [14:17:34.0000] Bakkot: contribute to, sure, but maintain? i should hope not [14:17:39.0000] Bakkot: please lmk if that's not true [14:17:42.0000] if i'm going to accidentally mutate something [14:17:51.0000] why don't i accidentally forget to enforce it being a record [14:18:16.0000] you don't solve forgetfulness by adding self-checked requirements [14:19:02.0000] devsnek: if I am calling a library, then either I need to a.) trust it not to mutate the object, b.) check its implementation, or c.) be guaranteed that it cannot mutate the object because it takes records rather than objects [14:19:07.0000] a.) and b.) both suck [14:19:17.0000] c.) only works if "it takes records" implies "it cannot mutate its arguments" [14:19:24.0000] i'm not sure i've ever had this problem [14:19:34.0000] like i don't feel the need to ensure libraries don't mutate things i pass to them [14:19:40.0000] /shrug [14:19:47.0000] c) there is the -entire- benefit of immutable data structures over mutable ones [14:19:48.0000] like I said, it's a correctness thing [14:20:04.0000] it means that you don't need to reason about a whole class of problems, because they cannot happen [14:20:07.0000] rickbutton: no one is taking away the immutable structure [14:20:24.0000] if records can contain mutable data, then yes, you are [14:20:26.0000] you're taking away the "deeply" part [14:20:31.0000] yes, i should say, deeply [14:20:32.0000] only if you create that [14:20:35.0000] no one is making you create that [14:20:41.0000] no one's forcing you to mutate regular objects [14:20:42.0000] use those [14:20:50.0000] so if u don't want it mutate , don't send record with objects... [14:21:15.0000] i'm mostly interested in records for compound values [14:21:18.0000] not for the immutability [14:21:26.0000] then you are not the main target audience [14:21:33.0000] it can have multiple target audicnes [14:21:37.0000] yes, and tradeoffs were decided for the immutable audience [14:22:30.0000] as long as you can still have a deeply mutable record [14:22:39.0000] devsnek "just be careful when writing it" means that you _do_ have to reason about this class of problems [14:22:47.0000] devsnek: that's not how the guarantees work [14:24:47.0000] i'm unconvinced but also not the majority so 🤷🏻 [14:25:04.0000] you're unconvinced that's not how guarantees work? [14:25:26.0000] i'm unconvinced the guarantee is useful enough to warrant this design choice [14:25:54.0000] ah, then i daresay that is a pretty fringe opinion on the benefits of the deeply immutable guarantee [14:26:44.0000] i've used languages like rust that enforce immutability and people invent a lot of ways out [14:26:55.0000] refs boxes pointers etc [14:27:16.0000] it has a type system [14:27:30.0000] the type system says the reference is immutable [14:27:36.0000] but you can get a mut ref to one of the children [14:27:42.0000] same vein [14:27:48.0000] I have no idea what this JSON.stringify example is doing. Why is serialization needed? [14:28:17.0000] i missed that [14:28:38.0000] We already have the serializer arg to encode a `BigInt` into whatever you want. [14:28:50.0000] you don't return a string from that [14:28:54.0000] i don't think [14:29:04.0000] You can return anything [14:29:08.0000] you can't return a bigint [14:29:11.0000] jridgewell i guess it allow u to deal with json generated by others. [14:29:14.0000] you can't return a string of digits [14:29:22.0000] or rather, you can return a string containing digits [14:29:28.0000] but it will be a string in the json [14:29:28.0000] but not a sequence of digits which will appear in the json [14:29:30.0000] not a number type [14:29:34.0000] yeah [14:29:47.0000] so you can't stringify bigints larger than 2**53 [14:29:57.0000] jridgewell: for example, this proposal would have saved twitter a *ton* of engineering effort when tweet IDs hit 2**53 [14:29:58.0000] some lib may output int64 [14:30:04.0000] shu: JSON.parse with a reviver is performance sensitive? [14:30:16.0000] https://www.irccloud.com/pastebin/Laqx6roR/stringify.js [14:30:20.0000] jridgewell: they had to add `id_str` next to `id` on every single API response, and input, rather than just providing a serializer/reviver [14:30:25.0000] michaelficarra: dunno, but JSON.parse in general is [14:30:30.0000] jridgewell: that's a string, not numeric digits [14:30:39.0000] michaelficarra: something worth verifying. this is asking for an extra allocation per reviver call [14:30:42.0000] jridgewell: when the (non-JS) server parses that, it will get a string and not an integer [14:30:59.0000] You need an interpreter on both sides [14:31:01.0000] shu: I imagine most of the performance sensitive cases do not take a reviver [14:31:02.0000] no [14:31:16.0000] jridgewell: non-JS JSON parsers handle numbers larger than MAX_SAFE_INTEGER just fine, since json allows it [14:31:19.0000] jridgewell: right now the use case is a json numeric literal that is greater than a double [14:31:23.0000] jridgewell: it is *only* JS that can't handle the full range of json numbers [14:31:36.0000] string literal also useful [14:32:17.0000] ljharb that's not true at all [14:32:20.0000] no? [14:32:24.0000] very few languages can handle the full range of JSON numbers [14:32:26.0000] ah [14:32:27.0000] ok [14:32:30.0000] most do not have arbitrary-precision floats [14:32:33.0000] JSON numbers are infinite [14:32:36.0000] even if they have bigints [14:32:40.0000] at least they can deal with int64 [14:32:44.0000] well, for example, the apache thrift json code - that tons of things use - produces and accepts numbers that JS can't [14:32:47.0000] js is unique in that it can't do 64 bits [14:32:51.0000] well mostly unique [14:32:55.0000] so all of twitter's non-JS stack could handle tweet IDs except JS [14:33:19.0000] discord uses snowflakes but it makes them strings [14:35:46.0000] michaelficarra: you're not convinced of the need for serialization? [14:35:59.0000] ah nvm [14:37:01.0000] the need to create arbitrary JSON [14:37:13.0000] there is not need, and if you do need that, you probably don't want to be using JSON.stringify [14:40:34.0000] arbitrary module namespace identifiers are cool and we should advance to stage 4 [14:42:53.0000] allowing a "*default*" export that's not the default export breaks the Shift AST :-( [14:43:10.0000] devsnek: +1 [14:44:01.0000] michaelficarra: *default* is runtime right? how did that leak into shift ast 👀 [14:45:03.0000] bradleymeck: the prose at the top of the spec says utf8 [14:46:12.0000] devsnek function declarations require a binding identifier, binding identifier for `export default function (){}` is `*binding*` [14:46:41.0000] ljharb: doh [14:46:43.0000] (not a choice I'm all that thrilled about) [14:47:03.0000] yeah I don't love that we did it, but it was following spec [14:47:07.0000] Bakkot: that's at runtime though [14:47:19.0000] in the ast that's `export default HoistableDeclaration[+Default]` [14:47:23.0000] it has no bindingidentifier in the ast [14:47:38.0000] devnsek: when we parse, we put a synthesised one [14:47:48.0000] yeah, we could have said function decls don't require a bindingidentifier, but that would be painful [14:47:51.0000] because almost all of them do [14:47:52.0000] to avoid making the BindingIdentifier of the FunctionDeclaration optional [14:48:07.0000] yeah my point was make the BindingIdentifier nullable [14:48:13.0000] just like the spec grammar [14:48:22.0000] fair enough though [14:48:52.0000] I think I still prefer "*default*" over optional BindingIdentifier of FunctionDeclaration [14:49:13.0000] yeah [14:49:26.0000] alternative is to make an explicit ExportFunctionDeclaration type or whatever [14:49:26.0000] i very much dislike putting a synthetic identifier [14:49:32.0000] devsnek: you ready to present Function#toString PR? [14:49:44.0000] i can be [14:49:46.0000] spec also puts a synthetic name, just in a differnet place [14:50:09.0000] devsnek: you're scheduled to be next [14:50:17.0000] michaelficarra: yeah saw that [14:50:19.0000] thx [14:54:10.0000] can the chairs advance the TCQ topic so I can add a reply? [14:56:59.0000] we still have four minutes to get monads into the language [14:57:05.0000] michaelficarra: if you have any desires for how you want me to refactor spec feel free to just bother me [14:57:50.0000] number destructuring is a really top-notch proposal, not convinced it's a wrong answer [14:57:57.0000] https://twitter.com/littledan/status/1285816792796061701 [14:58:06.0000] shu: core-js 2 did it, it broke a lot of things [14:58:14.0000] what [14:58:17.0000] shu: oh sorry that was iterable numbers, nvm [14:58:27.0000] yeah i'm talking about syntax [14:59:42.0000] bradleymeck: like… all of ecma262? [15:00:31.0000] for *default* [15:01:28.0000] since we gotta stop using it for [[ImportName]] and [[ExportName]] [15:37:18.0000] Could just use a [[Type]] enum? 2020-07-23 [17:12:52.0000] shu: What's this number destructuring thing [17:17:20.0000] https://twitter.com/__Jonathanks/status/1285874999589576705 [17:18:19.0000] omg [17:18:28.0000] (thanks, i just couldn't find it in the thread) [17:18:59.0000] Hmmmm tho, b should clearly be `.142` [17:19:30.0000] otherwise it implies `3.14` and `3.140` should destructure to different b values, which is weird with literals and impossible with variables. [17:21:58.0000] literals get weird anyway [17:22:07.0000] let a.b = 4503599627370496.001 [17:22:23.0000] they most definitely should destructure to different b values [10:17:58.0000] did mark go robot for anyone else [10:18:05.0000] no [10:18:27.0000] i had a feeling [10:19:06.0000] I think Shelley just joined the call actually [10:21:13.0000] What's the channel name? [10:21:40.0000] #tc39-inclusion [10:25:52.0000] Thank you mpcsh !!! [10:26:02.0000] please advance the queue [10:26:17.0000] ♥ [10:26:39.0000] hax's gist re "private in": https://gist.github.com/hax/5e94c7959703ea95d4ff9c9deac12988 [10:28:37.0000] curious about the "we" in the document [10:29:29.0000] iirc it refers to hax and his 360 colleagues [10:29:42.0000] they conferred 5ish hours ago [10:29:49.0000] thanks [10:32:38.0000] is there a link to the reification proposal? [10:38:35.0000] robpalme: https://github.com/jridgewell/proposal-private-symbols [10:38:39.0000] iirc [10:42:09.0000] right. that proposal did not achieve stage 1 when it was presented in Jan 2019. [10:42:09.0000] https://github.com/tc39/notes/blob/master/meetings/2019-01/jan-31.md#private-symbols-for-stage-1 [10:42:54.0000] Correct [10:43:11.0000] I do not plan on working on again [10:43:39.0000] (I'm in a work meeting, no idea what's you're talking about in the committee) [10:43:56.0000] bradleymeck makes a good argument for allowing `obj."property name"` [10:44:29.0000] hahaha [10:44:41.0000] +1 [10:44:44.0000] i like it [10:44:51.0000] but i have to insist [10:44:53.0000] on `obj.1` [10:44:55.0000] also we should allow `object.0` [10:44:57.0000] asi be damned [10:45:40.0000] are there actual ASI problems with that? [10:45:40.0000] Bakkot: jinx [10:45:43.0000] jridgewell: oh, do you have a different reified private fields proposal that's more up to date? [10:45:51.0000] yeah `object\n.0` is identifier and `.0` [10:45:55.0000] a numeric literal [10:46:00.0000] No [10:46:01.0000] ah right [10:46:03.0000] jridgewell: ah [10:46:12.0000] otherwise i'm sure we would already have it [10:48:45.0000] I am fine with `obj[0]` for numeric string properties [10:57:54.0000] this feels like bullying [10:58:05.0000] i am... also a bit wary here [10:58:59.0000] I also don't agree that the committee can't reject stage 3 advancement in an inactionable way [10:59:11.0000] michaelficarra: if you'd like to make a point of order and say that that's fine [10:59:14.0000] this proposal did not need to advance this fast [10:59:15.0000] yeah i have a concern there. [10:59:26.0000] see ystartsev's rejection of the function impl hiding for stage 3 [10:59:35.0000] yes exactly, i recently did this unilaterally [10:59:50.0000] it was accepted by committee [11:00:00.0000] wait is function impl hiding currently blocked [11:00:34.0000] ljharb: I'm not going to stop it from advancing because I want the feature, but I think the process just now was questionable [11:00:47.0000] I would be happier if we did not advance this to stage 3 at this meeting and brought it back next meeting after ljharb having talked more to haxjs [11:00:56.0000] i think we need to disseminate the difference in those proposals being rejected, but thats likely not best to do right now [11:01:02.0000] I agree with Michael [11:01:03.0000] Bakkot: can you point of order that [11:01:05.0000] yes. ff blocked as we considered it to have been advanced to stage 2 on the basis of having more benefits than it ultimately had. we had strong philosophical concerns about sensitive. for hide source we just weren't sure it was the right solution [11:01:09.0000] cc devsnek [11:01:10.0000] devsnek: yes, blocked with no actionable recommendation [11:01:10.0000] hmm, haxjs may have had connection issues [11:01:13.0000] it may be that the differences are irreconcilable and we have figure out if we're advancing it anyway but I don't think it needs to be rushed [11:01:39.0000] bradleymeck I will bring it up to the chairs to discuss between this topic and the next [11:01:42.0000] sure [11:01:44.0000] devsnek: on my side, since i blocked unilaterally, i joined the tooling meeting to try and understand concerns there and have made myself available to be convinced otherwise. i am still availabl efor that [11:01:44.0000] don't necessarily want to interrupt this topic [11:01:55.0000] i still cannot understand what is being said at all [11:01:56.0000] ystartsev: god it [11:01:57.0000] I can't hear anything... can you? [11:01:58.0000] got it* [11:02:17.0000] we have a lot of POO rn [11:02:28.0000] ystartsev: michaelficarra Bakkot fwiw i'm talking to hax on dm and will absolutely take 30 seconds later today to ensure my proposal stays at stage 2 if he feels like he didn't get the opportunity to object [11:02:28.0000] ljharb haxjs is that accurate regarding connection issues? [11:02:39.0000] ljharb: ty [11:02:46.0000] ljharb he did object pretty concretely [11:03:00.0000] and we tried to resolve those objections but they didn't sound super resolved [11:03:28.0000] ljharb: fwiw i do support ergonomic brand checks, i just want to makee sure we treat this the right way [11:03:34.0000] ditto [11:03:35.0000] totally understand [11:03:46.0000] no advancement is worth someone feeling bullied into it [11:03:58.0000] Bakkot ljharb: I want to make sure we also aren't setting a precedent around your claim that rejection of advancement to stage 3 must be actionable [11:04:03.0000] it seems ljharb asked me? it seems the connenction just lagged and i can't hear that [11:04:31.0000] haxjs: at the moment jackworks is talking, but we will take 30 s to address this in a momeent [11:04:35.0000] haxjs: would you like 30 seconds later to get your objection to stage 3 on record, and we can leave it at stage 2? or are you ok with stage 3 [11:04:59.0000] michaelficarra: Bakkot ljharb yes i agree here. I consider *stage 3* to have high bar for blocking advancement [11:05:22.0000] not ok with stage 3. but pls allow to read the notes again to see if i missed some arguments which may change my idea. [11:05:44.0000] I have an internal document documenting our process for our team that outlines this so that we react appropriately per stage. I think it might make sense to make this an updated version of the process [11:05:46.0000] haxjs: ok, please let us know asap, once you're confirmed one way or the other we'll make sure that's addressed and in the notes [11:06:03.0000] i retroactive understanding of this last discussion will be a process discussion is also a struggle since it was a desire to pin the `#x in` proposal to a reified proposal based upon a consistency around syntax implications. It wasn't necessarily a block on the syntax of `#x in` itself, but on the lack of a seen invariant of what `@ in @@` provides [11:06:25.0000] haxjs: noted in notes [11:06:30.0000] rricard: ty [11:06:48.0000] on this topic, I think we need to seriously reconsider our consensus process, possibly adopting TabAtkins' recommendation from a previous meeting (I think it was from TAG?) [11:07:24.0000] remind me what that recommendation was? [11:07:50.0000] michaelficarra do you ahve a TLDR or that process [11:08:06.0000] so the objection was valid, but requires adopting a consistency about the meaning of `@ in @@` regardless of what `@` is. that makes the argument hard to make as it isn't about semantic issues or about grammar issues, but around usage guarantees that we don't actually write down as preserved (or in my case i responded stating I don't think we guarantee it currently) [11:08:30.0000] personally i think there's a big difference in objecting to consensus on a stage > 2 proposal, than on a stage <= 2 proposal [11:08:41.0000] so it goes further in needing to convince people that the syntactic guarantees are something we are trying to preserve and must be solved [11:08:58.0000] we need a way to test for private fields that doesn't involve try/catch [11:09:18.0000] ljharb stage 2 is "something like this seems like it would work", stage 3 is "we are happy with this particular solution" [11:09:18.0000] MylesBorins: I don't want to misrepresent it, we should talk to TabAtkins and also look into process documentation of other standards-setting bodies [11:09:20.0000] i don't think people are arguing we don't want a way to test for them without try/catch [11:09:38.0000] Bakkot: stage 2 also means "we are committing to putting a solution to this problem in the language" [11:09:44.0000] michaelficarra: i am interested in changing our consensus process [11:09:47.0000] it does not mean that [11:10:05.0000] it absolutely does not mean that [11:10:06.0000] Bakkot: the process document literally says stage 2 signifies "The committee expects the feature to be developed and eventually included in the standard" [11:10:09.0000] i think we are arguing about what kind solution is viable due to breaking what are seen as existing invariants that are held by some of the committee [11:10:11.0000] so it 100% means that, explicitly [11:10:18.0000] ljharb "expects" is very much not "is committed to" [11:10:22.0000] ok fair [11:10:25.0000] extremely not [11:10:34.0000] that's a very subtle distinction tho imo [11:10:36.0000] W3C consensus is to seek strong objections; in the absence of those we go with "consensus", which is *not* unanimous but is more than majority; it's fuzzy, but basically if it's anywhere near close we don't call it consensus. [11:10:41.0000] those things are nowhere close to each other [11:10:58.0000] TabAtkins would you say that model closely reflects rough consensus? [11:11:18.0000] Bakkot: it also says post-acceptance changes expected are incremental [11:11:22.0000] Probably? Depends on exactly what you mean by that term, but they're in the same ballpark by my understanding. [11:11:41.0000] ljharb: but we can always drop a stage if we feel we have found something major [11:11:46.0000] sure [11:11:50.0000] fair enough [11:11:57.0000] ljharb right, so changing the proposal a bunch at stage 2 is weird [11:12:05.0000] per the process document [11:12:06.0000] but blocking it is not [11:12:10.0000] y'all see my comment about reading the READMEs on the reflector 😅 [11:12:10.0000] alright [11:12:38.0000] akirose: it was too small, didn't read [11:13:18.0000] use a screenreader [11:15:27.0000] i'm confused, was there a technical issue with haxjs's audio when ljharb asked for consensus for the private-in? [11:15:37.0000] that's the impression I got [11:15:43.0000] or perhaps a connection issue [11:15:49.0000] in that he was still objecting to stage 3, and then we got to discussing the validity of the objection? [11:15:51.0000] shu: I think so, yes [11:16:02.0000] ok [11:16:04.0000] shu: he had connection issues so that's why he failed to respond [11:16:32.0000] shu: so we'll take 30 seconds later today to either confirm he's changed his mind ok with stage 3, or confirm that his objection stands and the proposal stays at stage 2 [11:16:39.0000] *and is ok [11:16:51.0000] shu: regardless of the validity it seems fine to wait a meeting, but would be good for us to figure out what even constitutes a valid concern / why this is different from E.G. function impl hiding that had a opaque block [11:17:18.0000] bradleymeck: fair, agreed good for us to figure out [11:17:36.0000] i do see them as different [11:17:42.0000] but yeah good to figure that out as a group [11:17:55.0000] my assumption is the feeling is about adopting a claim of consistency is contentious [11:18:07.0000] blocking here feels like a bad precedent [11:18:18.0000] there's competing claims of what "consistency" means here [11:18:31.0000] ljharb: exactly [11:19:02.0000] and likely we need to see if we as a committee are adopting a specific invariant by moving forward with either path [11:19:06.0000] so the objection seems like essentially, "in my model of consistency, this makes things less consistent", whereas others feel the opposite [11:19:37.0000] e.g. adopting that `X in O` mandates `O[X]` succeed for all future things (regarding ordinary objects) [11:19:40.0000] I want to take this opportunity to remind people that for stage 1, we only need to convince ourselves that there is a problem worth solving; bringing forward a completely worked proposal like this distracts from that goal [11:20:01.0000] is chip on irc [11:20:18.0000] no. or at least not at the moment. [11:20:40.0000] we could also argue about succeed [11:23:29.0000] If obj[#x] will never exist, I have to object the proposal in current form. I would ask for alternative syntax, not overloading `in`. [11:24:03.0000] async context is kind of like incumbent but not on the realm scale :stares into the void: [11:24:23.0000] well it's like programmatic control over it [11:24:29.0000] the incumbent stuff is implicit at least [11:24:40.0000] implicit is even worse [11:25:40.0000] you don't even know what it could be, per my talk with you about only evaluating values and functions in realm A but the incumbent queueing up in realm B [11:25:42.0000] oh i think reflecting incumbents to be some programmable thing seems super bad to me [11:26:04.0000] akirose: we'll need 30s at some point to record in the notes that the proposal's still stage 2, and so hax can speak to the notes about why [11:26:31.0000] haxjs: ^ [11:26:56.0000] i think we need many more minutes than that, can we explain the why offline and in a way that we document what constraint we are trying to place on all future proposals [11:27:47.0000] not to set a precedent [11:27:48.0000] i still personally think this constraint applies to reification and constrains how any future reification must be designed [11:27:54.0000] but to record why i'm coming back in september to talk about it longer [11:28:18.0000] Cool cool. I do not plan to open it for discussion, so haxjs if you can keep it to just what you said above, we can add it to the notes, and discussions can happen over the next two months. [11:28:40.0000] bradleymeck: to correct my earlier misunderstanding; there's no plan for reification, just for https://github.com/tc39/proposal-private-declarations [11:28:49.0000] i do have concerns about constraining the whole language future as a whole without agreement on the importance of the constraint we want to keep [11:28:53.0000] bradleymeck: so `#x` would never be a value and `obj[#x]` would never exist [11:29:04.0000] jridgewell: is that right? ^ [11:29:04.0000] ljharb: currently [11:29:08.0000] bradleymeck: would this be considered an invariant? [11:29:29.0000] ystartsev: the question is, *is* it an invariant that `x in o` implies `o[x]` works [11:29:40.0000] ok, good thanks for the clarification [11:29:45.0000] which depends on how you define "works" [11:29:48.0000] since it could be a getter that throws [11:29:56.0000] ystartsev: yes, I am trying to state if we have a universal objection that limits all features of the language we need to canonize it [11:29:59.0000] littledan: the problem I have - and other delegates shared as well - is not against the feature but understanding what is currently proposed. [11:30:01.0000] or a proxy that misbehaves [11:30:11.0000] bradleymeck: we should also clearly identify the motivation [11:30:24.0000] ystartsev: agreed [11:30:38.0000] that is why i asked, to record an invariant without the motivation or "protectedd property" could leave us open to debt that we don't know how to deal with [11:30:46.0000] ljharb: I'd just state that invariants are for ordinary objects generally [11:30:49.0000] littledan: I'd like to understand this better, the presentation was confusing by many reasons, but it also made me think it was a set of different things it is actually not [11:31:02.0000] leobalter: Yeah, it was hard for me to follow the presentation. I recommend taking a look at their README. https://github.com/legendecas/proposal-async-context [11:31:03.0000] bradleymeck: instances with private fields are ordinary objects [11:31:17.0000] littledan: I can't do it in parallel with the meeting, that's the problem [11:31:17.0000] ljharb: yes, but around w/e we define "Works" to mean [11:31:21.0000] ah [11:31:25.0000] then yes [11:31:49.0000] littledan: I believe it would be best to recall this one and try to present it again another time [11:41:09.0000] drousso: async locals require overriding promise job execution [11:41:15.0000] which can't be done from userland [11:43:01.0000] ljharb: Just catching up. [11:43:14.0000] Yes, Private Declarations do not define a value [11:43:25.0000] They expand the syntax form only [11:44:18.0000] jridgewell: so would `obj[#x]` work [11:44:24.0000] Private Declarations should work fine regardless of the reification choice we make [11:44:28.0000] jridgewell: despite `#x` not being a value? [11:44:32.0000] drousso: also this is sort of like atomics in terms of usage, if you're using it you know how to use it and what it does [11:44:35.0000] It could be either Map based or Symbol based [11:44:40.0000] jridgewell: i meant the syntax [11:44:48.0000] jridgewell: or would i have to do `obj.#x` [11:44:50.0000] devsnek i would disagree with that assumption [11:45:00.0000] (This works, because the Private Declarations syntax is the same as normal class fields syntax) [11:45:01.0000] i mean its exposed in node right now [11:45:09.0000] i think there's a _lot_ of usage of atomics without understanding what atomics aree [11:45:14.0000] No, `obj[#x]` does not work. [11:45:18.0000] Only `obj.#x` [11:45:27.0000] It's the exact same syntax as class fields [11:45:34.0000] drousso: no i mean our design of atomics [11:45:48.0000] Purposefully, so that I didn't force any decisions on reification. [11:45:59.0000] drousso: the correct understanding of atomics is "always fast, always correct" [11:46:07.0000] we designed atomics with the assumption that they do confusing things and individual humans don't really use them [11:46:08.0000] jridgewell: ok thanks [11:46:23.0000] jridgewell: then haxjs' objection still applies, i think [11:46:39.0000] devsnek: well, no, it bottoms out at *some* individual humans [11:46:43.0000] just hopefully really tall ones [11:46:46.0000] lol [11:47:30.0000] am reminded how much i like the private declarations proposal [11:47:47.0000] really wish I'd managed to get use to use `private #x` for the class variant though [11:47:51.0000] private symbols but less orthogonal [11:47:59.0000] someone who is typing needs to mute [11:48:14.0000] sounds like cherry blues [11:48:15.0000] jridgewell: `private #x as x;` [11:48:24.0000] devsnek: private symbols but without breaking deep assumptions about the language and/or the guarantees you want from private state [11:48:24.0000] make it get really funky [11:49:28.0000] littledan this was said earlier [11:49:37.0000] this isn't a new thing [11:49:59.0000] We can make Private Symbols *branded* (act like current Private Fields) [11:50:12.0000] There are still some issues with Membranes… [11:51:02.0000] But I don't plan on working on this [11:51:29.0000] Bakkot: the "deep assumptions" thing seems like circular logic [11:51:34.0000] sorry for my comment. I missed some context here. [11:51:43.0000] the deep assumption that you can enumerate keys is the exact thing private symbols are supposed to not do [11:51:56.0000] so like if you're dealing with private symbols [11:52:02.0000] for `#x in obj`, please check the conclusion i put in the notes and update as needed (cc haxjs) [11:52:10.0000] "wait why is my private symbol not enumerable" seems like an uncommon thing to think [11:52:22.0000] devsnek enumerating keys isn't the thing I'd worry about so much as `a[x]` is prototypical [11:52:28.0000] (i updated the original notes section instead of adding a tiny new one) [11:52:31.0000] the only reason a.#x not being prototypical works is because it is new syntax [11:52:40.0000] Bakkot: it could just be prototypical [11:52:41.0000] but if you reify private fields then that stops being new syntax [11:52:42.0000] oh nvm, i'll update the continuation [11:52:55.0000] devsnek right, and then you get the "breaking guarantees you want from private state" [11:52:55.0000] and people who want own properties can do own property checks [11:52:57.0000] one or the other [11:52:59.0000] that's the point [11:53:00.0000] it composes perfectly [11:53:03.0000] with the existing language [11:53:10.0000] and how existing properties work [11:53:13.0000] it makes private fields not do the thing that private fields are for [11:53:23.0000] they're for lots of things [11:53:35.0000] they're for having guarantees about your code without accidentally exposing API [11:54:43.0000] ok to flip the argument around then you could argue that because its so obvious that they shouldn't be prototypical [11:54:48.0000] no one would be confused by them not being prototypical [11:55:00.0000] that works fine when it's a different syntactic form, as they are in the current proposal [11:55:12.0000] that stops working the instant they are reified and using the regular property access syntax [11:55:14.0000] but then they don't work with any concepts in the language [11:55:18.0000] and we end up having this issue [11:55:50.0000] `o?.#[k]` 🚢 [11:56:30.0000] they work fine with the language [11:56:35.0000] they work just as well as local variables do [11:56:58.0000] except that they have more limitations on where they can be declared, which there is a lovely proposal to relax [11:57:03.0000] but they don't have the usage of local variables [11:57:45.0000] they compose more naturally as keys of objects [11:58:27.0000] they work fine as keys of objects as well, except for the `in` limitation ljharb is proposing to rectify [11:58:35.0000] and adding them [11:58:37.0000] and deleting them [11:58:43.0000] and dynamically doing anything with them [11:59:05.0000] well i guess you can technically add them using super tricks [11:59:13.0000] you can't add and delete and dynamically refer to local variables either [11:59:21.0000] Adding and deleting are intentional restrictions [11:59:21.0000] they aren't local variables though [11:59:37.0000] they are somewhere between local variables and regular properties [11:59:40.0000] you can't add properties to a sealed object either, or delete a nonconfigurable property [11:59:41.0000] giving you the nice parts of both [11:59:56.0000] qq ystartsev: would it be realistic to send someone else from Mozilla to some meetings? is it delegable? [12:00:02.0000] ljharb: them being nonconfigurable is orthogonal to them existing [12:00:38.0000] akirose: i make those meetings available to all members of the spidermonkey team [12:00:46.0000] but generally i am the only one that atteends [12:00:56.0000] also i have more context for some issues [12:00:58.0000] oh i assumed that part. i mean can you push someone else to attend half [12:01:54.0000] ystartsev: there's been an overflow last time [12:02:05.0000] it was not possible to schedule all of the topics given bi-weekly [12:02:41.0000] ystartsev: wait why would doing more work in between mean the meetings themselves become burdened? [12:02:52.0000] if we move a lot of topics forward [12:04:16.0000] ystartsev: fwiw it is freeing once you internalize that you shouldn't be a single point of failure for all JS features for SM [12:04:16.0000] fortnightly! [12:04:27.0000] akirose: #temporaldeadzone [12:04:36.0000] if implementer feedback is really crucial for some proposal, and you can't make it, could you delegate? [12:04:43.0000] shu: i don't consider myself that, i also make it available to other sm engineers [12:05:03.0000] if its really crucial and I don't have the expertise, i will have another delegate with me or have someone there who knows [12:05:39.0000] this isn't an issue about delegation, its about the reality [12:05:57.0000] unless a feature actually needs implementer feedback, its likely that no one will come. i don't think that is ideal and i have limited time [12:05:59.0000] it's relevant—biweekly is a really confusing term. [12:06:39.0000] akirose: I meant we were already discussing in #tdz [12:06:53.0000] ystartsev: sorry i don't understand what the reality is you're referring to [12:07:06.0000] are we going to reconvene at 13:06P or 13:00P? [12:07:09.0000] if you are already comfortable to not coming to every one, where does the pressure come from to come to every one? [12:07:21.0000] im not sure why my position is a problem [12:07:29.0000] i didn't say that you have to do it biweekly on my account [12:07:36.0000] i said that i havee an issue doing it weekly [12:07:54.0000] and that issue stretches to the fact that at present, i am the only person from mozilla who has signed up to go to all of these [12:08:09.0000] I prefer waiting until we have too many topics for the fortnightly meetings [12:08:11.0000] it is fine to do it weekly, i don't know if i will make it, thats all [12:08:36.0000] fwiw weekly *on tuesdays at 9am* is a problem for me because that's one of my mornings with the kids, and so far tuesdays at 9am is the time most often selected :-/ [12:08:50.0000] ystartsev: sorry, i don't actually want it weekly that much [12:08:57.0000] ystartsev: i was trying to understand the "pressured to come" issue [12:09:02.0000] which i am worried about imposing upon others [12:09:16.0000] so, it would suck but i would make it work? [12:09:29.0000] this was something i brought up when we were first scheduling [12:20:49.0000] yes, again, very sorry for my inappropriate comment with Hax's topic. I didn't realize it had been discussed here, and the resolution seems reasonable for now. [12:21:03.0000] shu: i cleared it up with leo -- we are on the same page [12:44:45.0000] ystartsev: great, and is that page the same as what you said before? [12:49:46.0000] leobalter: you had suggested several proposals for incubator calls, remind me what they were again? [12:52:27.0000] shu: basically -- if there is enough content to do it weekly it should be done weekly [12:53:07.0000] +1 [12:54:58.0000] late meeting, its harder to communicate well! [12:55:14.0000] hear hear [12:55:24.0000] i bet i'm gonna be super cranky for the european timezoned one [12:55:56.0000] well, i have to say i really wish japan was in person [12:56:10.0000] not looking forward to the remote version 😬 [13:04:00.0000] shu I'm sorry I was afk [13:12:30.0000] shu: if we're looking for more, I would nominate gibson042's JSON.parse proposal [13:15:13.0000] To clarify (since I was asked), by "yes, again, very sorry for ..." I meant about how I didn't realize the expression of the objection was agreed-on in this room, and I was thrown off by it was raised [13:17:51.0000] very excited for this proposal [13:18:40.0000] me too [13:19:50.0000] shu, please let me know what are the best ways I can help co-facilitating the incubator calls. We can schedule a chat if you prefer or just use irc/email too [13:19:57.0000] note that WebAssembly.Memory can already resize things, this is just about better ways to deal w/ all the fallout of how it must do things [13:20:22.0000] this wasm grow detach is like the #1 slowdown of js<->wasm rn (non-scalar types aside) [13:40:12.0000] did jordan get skipped [13:40:15.0000] yes [13:40:20.0000] it's ok tho [13:40:31.0000] i can ask both of mine together [13:41:21.0000] why can't i add a response to this [13:41:39.0000] the queue needs to be advanced [13:41:50.0000] akirose ^ [13:41:55.0000] i've preserved my item [13:42:13.0000] it's a clarifying question [13:42:29.0000] akirose: it was one for the previous topic; waldemar skipped to the next full topic [13:42:30.0000] is why you can't reply [13:42:30.0000] akirose: we're on " Timing considerations" [13:42:35.0000] ohhh [13:42:38.0000] right [13:42:55.0000] devsnek: Waldemar may have gone there [13:42:55.0000] akirose: waldemar had already asked "auto length" and skipped my clarifying question straight to "timing considerations" [13:42:58.0000] oh i see what you're asying [13:43:01.0000] saying* [13:43:38.0000] akirose: i think that next item, timing, by wsdferdksl is covered? [13:44:01.0000] y [13:55:55.0000] 🎉 [13:57:42.0000] leobalter: will do, thanks for the offer [14:00:14.0000] aren't EIM invariants very unusual in actually being documented? [14:01:08.0000] we need to bring RFC 2119 into ecmascript [14:01:21.0000] hehe [14:01:55.0000] is something truly a specification without that first paragraph [14:03:18.0000] ohh so this is about doing what we do for EIMs in lots more places [14:03:36.0000] I assumed this presentation was going to be about the rationale repo, my bad [14:07:40.0000] we've made changes to the spec to keep LR(1) [14:07:52.0000] i think it was some export syntax? [14:09:56.0000] Import syntax [14:09:59.0000] But yup [14:10:15.0000] there's still an open bug here [14:10:15.0000] was it +Default? [14:10:28.0000] guess not [14:10:33.0000] with parsing `for ( async of` [14:10:50.0000] It was redefining the import attributes to be valid identifiers [14:11:11.0000] Right now, you can `import { for } …` [14:11:34.0000] And that should throw at parse time. [14:12:46.0000] xs and qjs accept that [14:13:42.0000] wsdferdksl excluding SAB over high-res timers seems quite prescient these days [14:14:16.0000] Right, the change was to make that a parse error [14:14:24.0000] But we had to undo it because it broke LR(1) [14:15:04.0000] wait so this is in the spec or in a separate repo? [14:15:13.0000] import {import as ...} is wonderful [14:15:25.0000] I want to ask a question but I feel like I missed something [14:19:11.0000] Ohh, it _was_ `export` [14:19:12.0000] https://bocoup.com/blog/i-slipped-on-javascripts-banana-peel [14:23:48.0000] i remember that blog post! [14:23:58.0000] I wonder if should have a place for RFCs at TC39, like this post [14:24:53.0000] this looks interesting [14:28:56.0000] ystartsev: making repos is cheap; i'd prefer a new repo over the reflector [14:30:50.0000] yeah I would like a new private repo, announced on the reflector [14:30:57.0000] that seems like the way to go [14:30:59.0000] So my question was about where this was _intended to_ live [14:31:31.0000] i'd assume in the tc39 org - in a document in the spec repo, or in a separate repo [14:31:39.0000] eventually it should be public [14:31:58.0000] Should it be a PR to How We Work? [14:32:42.0000] tc39/process-document? [14:32:43.0000] sure, once mostly agreed upon that would work too i think [14:32:59.0000] but if it's meant to be normative it seems like it should be in one of the repos related to normativity (process document is a good candidate too) [14:33:18.0000] i think choosing between how we work vs process document will distinguish it's… formality? [14:33:54.0000] i would hope that these invariants, while changeable, otherwise constrain proposals [14:35:24.0000] MylesBorins: you are unmuted [14:35:34.0000] tyvm [14:35:38.0000] that could have gone... badly [14:36:11.0000] akirose I vote how-we-work because less formal hopefully means less exegesis of the document during meetings [14:37:58.0000] i concur [14:39:00.0000] i thought how-we-work was considered as rough guidelines. whereas the process doc is more akin to rules. [14:39:11.0000] yup [14:39:26.0000] yeah how we work is guidance on how to participate [14:39:34.0000] i would prefer these end up as rules, but obv it's fine to evolve there from being guidance [14:39:50.0000] changeable rules, ofc [14:40:06.0000] maturing via HWW seems fine [14:40:20.0000] I would prefer not rules, because the rules for this kind of thing need to be kind of loose, in my experience [14:41:06.0000] the whole business of language design is weighing values, and it is impossible to write down all the values and their weights [14:41:12.0000] super sad about the loss of Object.prototype.toString :-( [14:41:28.0000] is it too bold to say that infallible allocation is a good invariant [14:41:59.0000] Bakkot: wasn't that ystartsev's whole thing just now? [14:42:20.0000] michaelficarra ystartsev had two things: invariants in the language, and some norms around process [14:42:34.0000] invariants in the language seem good to write down [14:42:44.0000] the rules for advancement seem like they need to stay more flexible [14:42:51.0000] fair [14:52:36.0000] ljharb: eqeqeq doesn't autofix [14:52:40.0000] it refuses [14:52:44.0000] that is true [14:53:35.0000] Bakkot: we do have the "eliding the process" segment which might help [14:53:55.0000] its part of the reason I wrote a more strongly worded approach [14:54:11.0000] but i am also not opposed to loosening [14:55:13.0000] ystartsev I haven't had a chance to read what you actually wrote yet, so I can't actually speak to this [14:55:15.0000] oh man those pings on the line are throwin' me [14:55:39.0000] Bakkot: thats in the existing process -- i will get my text up in a public location asap [14:55:54.0000] ah, yeah [14:55:55.0000] i don't think i can do it today, as i am afraid i might make a mistake (too tired) and there were some restrictions [14:56:10.0000] not rush [15:00:42.0000] Have to head out friends. Thanks for a great meeting!! [15:00:48.0000] im also out [15:00:54.0000] thanks everyone for the great meeting [15:00:59.0000] big thank you to the chairs and everyone who helped facilitating this meeting [15:02:27.0000] Have there been any messages in #tc39-beginners? [15:02:49.0000] last was 1.5 hours ago [15:02:51.0000] Hah [15:02:52.0000] This is the first time i know this channel exist [15:03:04.0000] jridgewell: https://www.irccloud.com/log-export/111793/irccloud-export-280155-2020-07-23-17-02-54.zip [15:03:10.0000] The previous link was t39, not tc39 [15:03:25.0000] I've been idling in a misspelled channel name [15:03:39.0000] its your channel now [15:03:53.0000] someone have a link to the beginners channel? [15:04:19.0000] #srennigeb-93ct [15:05:09.0000] thank 2020-07-24 [08:05:31.0000] person trying to work around being banned from whatwg org using tc39? https://github.com/tc39/proposal-built-in-modules/issues/59 [08:38:52.0000] a word of warning against over-engaging there, i prefer feedback threads like that to be as short and with as high an SNR as possible [08:58:35.0000] shu: 👍🏻 [09:03:53.0000] incorrectly quoting Frantz Fanon in that thread is... a choice? [09:08:16.0000] we should probably hide all those comments as off topic [09:08:21.0000] +1 [09:08:48.0000] looks like i can; will do now [09:14:32.0000] just ... wow [09:54:37.0000] > Proposals which have fulfilled the acceptance criteria may not be blocked from reaching stage 1 unless there has been a very similar proposal that has already been through the process and has not advanced. [09:55:00.0000] ystartsev: isn't the precedence for saying "i don't think the committee should be solving this problem" [10:01:44.0000] yeah that seems false [10:01:53.0000] we've definitely blocked proposals on the basis that they seem like bad ideas [10:06:45.0000] indeed, blocking stage 1 means "there's no point wasting committee time on this because we'll never have consensus that this is a problem worth solving" [10:06:59.0000] it's rare but it has been, and should be allowed even if it's a new proposal concept [10:45:17.0000] haxjs: I can't find your abbreviation / name on https://github.com/tc39/notes/blob/master/delegates.txt [10:46:07.0000] bradleymeck: JHX iirc [10:46:24.0000] https://github.com/tc39/notes/blob/master/delegates.txt#L154 [10:46:38.0000] thx! [11:20:11.0000] How can we add more channels to https://freenode.logbot.info ? We created a couple new ones last meeting ,and I want to make sure they're up there [11:22:54.0000] i think you just invite the logger bot to each channel [11:47:05.0000] PSA: please add yourself to incubator call topics if you are a stakeholder https://github.com/tc39/incubator-agendas/issues/10 [11:50:58.0000] anyone around to complete some proposal repo transfers? [11:51:04.0000] (and also to give me access back) [11:51:39.0000] i can do the latter [11:52:24.0000] shu: already had done one, the other's done now [11:52:28.0000] chairs can bounce them whenever [11:52:31.0000] ljharb: ty [14:53:50.0000] ljharb, others: Feel free to preemptively ban that guest271314 person; they've been banned from HTML *and* CSS for being both useless *and* extremely hostile about it. They offer absolutely nothing of value. [14:55:32.0000] TabAtkins I think their last comment made that pretty clear [14:55:41.0000] yup [14:55:43.0000] out of morbid curiosity, do you have a link to the past incidents on hand? [14:56:03.0000] they linked to their own incidents in webaudio; i could dig them up in css world if you really want to see [14:56:57.0000] nah, I'll track them down if I get bred [14:58:27.0000] Oh I misremembered, he hasn't interacted significantly in CSS, but rather in WICG stuff. Got *real* bent out of shape over the requirement to provide a real name for patent policy reasons. [15:09:39.0000] lol [15:10:05.0000] TabAtkins: thanks, atm it's not code-of-conducty but i'll keep an eye out for when it is, and will surface it to the group [15:14:38.0000] ljharb: Can you make me an admin in tc39-transfer? [15:15:36.0000] pretty sure only the chairs are admins there [15:17:00.0000] i'm one in the transfer org [15:17:07.0000] TabAtkins: what do you need admin for? [15:17:26.0000] That's what the instructions say to ask for so I'm capable of transferring a repo into it. [15:17:31.0000] TabAtkins: ah, you weren't in the org at all - i just sent you an invite [15:17:41.0000] should be able to accept it at https://github.com/tc39-transfer [15:17:50.0000] Perhaps also adjust the instructions at https://github.com/tc39/proposals#onboarding-existing-proposals then please [15:17:56.0000] good call, on it [15:18:07.0000] oh whoops [15:18:19.0000] yeah everyone should be an admin of tc39-transfer I think [15:18:52.0000] nah everyone's just members, but members can create repos so it's fine [15:31:51.0000] ah, got it [16:04:48.0000] TabAtkins: readme updated [16:05:04.0000] danke 2020-07-25 [09:13:29.0000] brad4d ljharb , oh it seems my abbr / name is rollbacked when notes repo was moved to tc39 org, i'll fix it myself when I have time. [09:28:12.0000] haxjs: what should it be? [09:38:42.0000] ljharb https://github.com/rwaldron/tc39-notes/pull/124#issuecomment-537965788 and I remember mathiasbynens have fixed it in some follow-on PRs, but lost now. [13:12:25.0000] huh, strange it was lost [13:12:49.0000] a PR that updates the delegates list and also all the notes with "JHX" in it would i'm sure be no problem to land 2020-07-27 [15:13:25.0000] someone mind moving https://github.com/tc39-transfer/proposal-item-method to tc39? i know i did the transfer on a friday, so no worries [15:17:09.0000] one of the chairs will have to do it; there's 5 of them waiting. URLs will redirect tho, so there shouldn't be a rush [15:19:10.0000] ah kk 2020-07-28 [16:17:15.0000] TabAtkins: doing the `/notice #tc39-chairs msg` help a lot. It proved very effective in my experience [16:18:12.0000] as in: there were times where more than one chair tried to address the same issue in less than a minute after I messaged them. :) 2020-07-30 [04:40:16.0000] How can we add channels to logging? [04:40:50.0000] We agreed to log all the TC39 IRC channels, but we've created a number of them that are not logged yet [05:33:25.0000] littledan: `/invite globbot` [05:35:08.0000] devsnek: Thanks, done where I could, asked someone else to do it where I couldn't [09:06:48.0000] littledan: wait [09:06:55.0000] should this channel be logged? [09:07:03.0000] I thought this one was supposed to be private [09:07:07.0000] I guess this channel is the exception, somehow [09:07:31.0000] globbot is here already [09:07:34.0000] we agreed that all other channels would be logged, and that this one would be open in an unvoiced way [09:07:47.0000] oh, I think it's good if it's logged, just we don't want to distribute the logs [09:08:58.0000] littledan: the logs are public [09:09:04.0000] here: https://freenode.logbot.info/tc39-delegates/20200730 [09:09:23.0000] hah that's us right now! [09:09:35.0000] it is! [09:09:40.0000] Logs have to be public for some companies to allow technical communication [09:09:54.0000] I didn't know it included this channel [09:10:02.0000] but if this is intended, then we're all good [09:10:12.0000] I am +1 with the logs of this channel being public [09:10:23.0000] we can keep the logs public and keep the channel invite-only, I think that should be acceptable. [09:10:30.0000] I guess I just didn't remember where we landed [09:10:39.0000] ryzokuken: I believe this channel lets anyone join, but only voices delegates [09:10:48.0000] ^ Yup [09:10:51.0000] I thought that was #tc39 [09:10:57.0000] hmm, my bad then [09:11:02.0000] No, #tc39 is completely open to all [09:11:09.0000] right [09:11:12.0000] I thought this channel was invite-only to delegates [09:11:15.0000] #tc39-delegates is open for reading, but only delegates can message [09:11:21.0000] ah [09:11:23.0000] okay [09:11:36.0000] that's exactly what I thought, +m [09:11:41.0000] I just noticed the flag 2020-07-31 [08:39:13.0000] do we announce calendar events like the incubator call anywhere except the calendar itself? [08:52:34.0000] incubator calls are announced on the reflector [08:52:49.0000] e.g. the one which is ini 8 minutes has a thread here: https://github.com/tc39/Reflector/issues/308 [08:55:57.0000] bradleymeck: someone (i think jordan?) tries to pin the next one, but we only have 3 pin slots so not always pinned [08:56:16.0000] bradleymeck: but yeah, each incubator call is always announced on the reflector [09:10:28.0000] today's has been pinned for a month, fwiw [09:11:28.0000] bradleymeck: beyond irc, reflector issues, and the calendar, what would help announce them? [09:15:57.0000] not really seeking more, i just don't see much explicit short term announcement (i just read the calendar normally) [09:19:53.0000] kk [10:00:28.0000] shu bradleymeck: WRT prioritization: this seems meta. Goals vs Motivations. [10:01:37.0000] leobalter: agree [10:02:24.0000] leobalter: not sure i understand what you mean by meta there [10:02:36.0000] leobalter: i think it directly impacts how we weigh tradeoffs [10:04:56.0000] well, I'm just pointing on both sides I feel like things are being put as Goals or Motivations. [10:05:44.0000] sorry i don't follow [10:05:47.0000] both aspects are very important for any things we work on. [10:06:25.0000] sorry the irc / text is never helpful. [10:07:10.0000] shu: i don't think we were discussing the language's ability to provide implementation or JS recreation of guarantees, which is kind of off topic/meta discussion. it can be somewhat related to auditing of what is/will be guaranteed but not necessarily working towards a scope of what is in/out of bounds [10:07:38.0000] we disagreed on bounds at the time, but not necessarily in direction [10:07:49.0000] i think i'm fundamentally kinda confused about what we're discussing, but that makes me feel hopeful? [10:08:01.0000] sorry i'm not all here, fucking plumbing... [10:09:02.0000] I don't feel able to help clarifying through text chat, so I'd rather defer to a next call or something. [10:09:03.0000] shu: i think we all agree on some base premises (side effects hard to deal w/, ability to make guarantees about JS code is primary) but are too ingrained in specifics and likely having trouble coming to terms that are mutually agreed upon [10:09:43.0000] e.g. the Node problem was a subclass of Set/Map calling @@iterator this week which meant non-host code could muck with things [10:10:12.0000] bradleymeck: ah, i think node and the browsers might not have much disagreement here in practice [10:10:19.0000] or exfiltrate things... but it wasn't about arbitrary code execution [10:10:55.0000] bradleymeck: but i do stand by the Proxy point i made. Proxies added a lot of complexity and arguably was a detriment to the security of the implementation, all the while enabling a particular solution to a kind of security guarantee [10:11:01.0000] shu: we participate in the SES calls for example but are not intending to ship SES/membranes [10:11:33.0000] shu: I am not in disagreement but there was cross talk about various things only be important at VM implementation [10:11:45.0000] which isn't where most of the CVEs in our ecosystem come from [10:11:55.0000] +1 [10:12:40.0000] we do ship --frozen-intrinsics though and that does solve a lot of issues 😉 [10:13:10.0000] shu yeah I think the complexity of new features vs implementation burden point is well taken [10:13:12.0000] just auditing JS code to know what it is trying to do is basically an impossible task [10:15:52.0000] so you end up having to limit host APIs, and for a lot of the times you can audit a few small bits of code that need access to powerful things (net/fs), but the ability to even audit or guard that is non-trivial like you said. hence needing to recreate various guarantees or completely disable the API. for lots of things you can't disable stuff (http server disabling http!?) [10:16:22.0000] so you do end up with some level of granting authority by exposing/passing APIs around, that is the main contention i think [10:16:43.0000] various things about what is in/out of bounds is largely still undiscussed