2020-03-02 [11:50:09.0000] this seems like an annex b grammar question that i'm not sure about - can anyone weigh in? https://github.com/acornjs/acorn/issues/923#issuecomment-593581439 [11:53:39.0000] I think JSC has bugs in this area [11:54:44.0000] engine262 uses acorn anyway [11:54:52.0000] it's very sad and I need to fix it [11:56:21.0000] ljharb: i agree with marjin's response there, but let me see what the spec says [11:57:01.0000] oh wait, that's a for-of [11:57:15.0000] there's nothing in annex b for for-of [11:57:37.0000] ah ok, then just a grammar question i'm not sure about :-) [12:45:56.0000] ah yeah I missed that it was for-of too, whoops 2020-03-05 [10:31:22.0000] hey, so what are people's thoughts about coronavirus now? [10:45:02.0000] Googlers can't travel thru at least May 31st [10:45:19.0000] (We'll probably end up cancelling the April CSSWG meeting.) [10:46:13.0000] to me it seems overly paranoid, but everyone's entitled to make that decision for themselve [10:46:14.0000] s [10:46:35.0000] i'd be more worried about countries closing borders and people getting stranded, than about actually catching anything [10:47:41.0000] Being trapped in an airplane for multiple hours with a coughed would make anyone paranoid. [10:47:55.0000] Cougher* [10:48:30.0000] personally it doesn't really worry me that much [10:49:05.0000] my wife and i are going on vacation to mexico in a week and a half. we'll wash our hands, and avoid letting people cough on our faces, and i think it'll be fine [10:49:21.0000] but either way the march meeting is surely going to be heavily remotely attended [10:51:28.0000] hopefully apple's got super beefed up AV [10:52:34.0000] on the one hand, there may be enough of us who are local to justify meeting in person; on the other hand, shu pointed out to me that this could be an apt opportunity to try a remote plenary and see what works and what doesn't, which I can't deny [11:01:02.0000] as long as apple's willing to host, and there's locals willing to attend, i'd prefer to go to a location that's not my house or my office, with good internet, even if most people are remote [11:22:38.0000] I imagine that most have already booked travel, as well. [11:22:51.0000] (if their company hasn't disallowed it) [12:22:03.0000] I'm more intrigued by what's gonna happen at the end of May [12:22:09.0000] like, what's the trajectory here? [12:22:30.0000] if we're in mega-pandemic land, i'll probs cancel the in-person of PayPal's Chicago meeting [12:22:46.0000] and if it's starting to chill out, I'll look forward to seeing all your smiling faces [12:33:14.0000] rickbutton: out of all the reasons to not cancel, "saving company money" is bottom of the barrel for me [12:33:57.0000] ljharb: we probably shouldn't say things like "than actually catching anything"? [12:34:37.0000] shu: 100% agree, but some pay for travel out of pocket [12:34:55.0000] rickbutton: oh yes definitely, emphasis on saving *company* money [12:35:44.0000] but so far i'm seeing twitter and microsoft recommending their entire workforce in bay area (and seattle area) to wfh until end of the month [12:36:03.0000] agreed though to that point, paypal's current moratorium on nonessential business travel is at least in part due to a concern of employees being caught up in a quarantine or other dragnet away from home. [12:37:35.0000] i think i do agree with deferring the decision to the host as the most reasonable thing to do here [12:40:34.0000] akirose: well, 1) santa clara county is home to known cases 2) delegates presumably having very varied risk profiles for exposure [12:48:21.0000] oh i get it [12:48:29.0000] <-- sick person [13:02:58.0000] shu: oh i meant, worried for myself. people can be worried about whatever they like :-) [13:10:26.0000] (in case i was sending the wrong message, i think everybody's personal, financial, and employer concerns should be respected; i didn't mean to be cavalier about risk) 2020-03-06 [20:14:53.0000] uh damn [20:15:52.0000] we got "please cancel attendance at any events, even if you're scheduled to speak" -- it's in the context of the travel ban but I think it means it period [20:16:23.0000] plenty of time for that to get lifted by 3/31 but... :-| [20:25:05.0000] tc39 plenary isn't an event, it's just an unusually pedantic meeting [20:31:15.0000] works for me :shipit: [20:31:52.0000] plenary is the norm everything else is an event [08:50:53.0000] bterlson: assuming I'm not prohibited from being there, I'd be happy to help facilitate πŸ˜“ [09:10:55.0000] hahahahahahaha Bakkot [10:14:11.0000] thank you, Ross! [15:36:09.0000] OH HI delegates [15:36:28.0000] can you please ensure that your availability is up to date in the doodle for the next meeting [15:36:35.0000] it is really important for the host to know numbers [15:40:04.0000] handy reflector link: https://github.com/tc39/Reflector/issues/270 [15:40:30.0000] (please do not post the doodle link here, since this channel has public logs; you can get there from the reflector, which is not public) 2020-03-07 [16:23:59.0000] now _definitely_ update the doodle. as in remove yourself once your flights are canceled. (see reflector) [16:25:23.0000] @channel [16:25:25.0000] "With an abundance of caution and the current sentiment in our industry the chair group and the host organization for the March plenary have decided to cancel the in person meeting and move to a remote format. We will follow up with more specific details next week but wanted to inform everyone as soon as we made a decision so that you have time to cancel travel arrangements. If you need any support from us with this [16:25:26.0000] please do not hesitate to reach out" [16:31:39.0000] rkirsling rickbutton mmarchini JaseW ghermeto Bakkot ljharb pouwerkerk you are marked as attending in the doodle so want to make sure you see this [16:31:51.0000] sidebar, who is globbot ? [16:31:56.0000] the logging bot [16:31:59.0000] AHhh [16:32:00.0000] hi globbot [16:32:05.0000] he never attends in person :( [16:32:09.0000] i see it, thanks. not stoked, because i have nowhere with good internet to spend 3 days that's not in my house. [16:32:30.0000] ljharb maybe you can find some other bay area folks to meet up with? [16:32:52.0000] sure, where would we go [16:32:56.0000] πŸ‘ thanks for the heads up! [16:33:08.0000] don't the sbuxs there have google wifi [16:33:25.0000] i can't do a video call in a starbucks, it's too loud [16:33:27.0000] Thanks [16:34:25.0000] I suspected so [16:34:44.0000] everybody's office won't allow visitors; public places are too loud; my home has children running amok in it; i can't book any space in my office for 3 days :-/ [16:35:04.0000] if anyone has a suggestion, that'd be helpful <3 [16:36:14.0000] can you get your work to pay for a we work? [16:36:55.0000] MylesBorins: I respect that, thanks [16:37:34.0000] I'm not even certain that I'm allowed to go at this point, I was just trying to be optimistic, so this will prevent me from getting myself into trouble :P [16:38:03.0000] ljharb or like a hotel [16:39:17.0000] a wework might be ok, but this meeting was supposed to cost them nothing because it was a nontravel one :-/ [16:39:22.0000] a hotel won't have good enough internet, i suspect [16:39:44.0000] i'll certainly look into a wework-like solution, thanks [16:40:04.0000] I would guess this probably won’t be the only non-travel one this year [16:41:58.0000] MylesBorins: unregistered from in person and registered to remote, thank you for pinging me [16:43:48.0000] I'm still moving forward with planning Chicago in June [16:44:23.0000] If I have to cancel I have to cancel but I don't want to be caught in a situation where there's no heightened travel-related concern anymore and we haven't had a face-to-face in four months [16:45:35.0000] strong agree [16:48:22.0000] rickbutton: it was going to be the only non travel one for me, since it’s the only one in the Bay Area. Now there’s zero in the Bay Area :-/ [16:49:24.0000] it's in the Bay Area [16:49:26.0000] for you [16:50:31.0000] lol well yes. i mean it was going to be the only one i didn’t have to expense something for [16:51:09.0000] I’ll figure something out. If anyone else has a space that has good internet and can host locals, that’d be great too [17:06:31.0000] I have a studio apartment but um [17:06:35.0000] yeah. [17:07:01.0000] πŸ˜‚ [17:42:23.0000] ljharb: can you edit https://github.com/tc39/proposal-import-meta/issues/17 to include webpack, babel, and rollup [17:43:32.0000] actually webpack is debatable, there's a loader but its not included by default [18:12:12.0000] i think default is what matters most for this one [18:22:10.0000] ljharb: rollup can be checked off, and engine262 unflag criteria is being in ecma262, so perhaps its ok to check it off too? [20:28:42.0000] you don't unflag in stage 3? [23:29:19.0000] ljharb: my goal is that regular engine262 should be the current normative specification [23:29:59.0000] stage 3 is disabled by default but very easy to enable, for example the big check boxes on engine262.js.org [23:31:18.0000] s/stage 3/other features/ 2020-03-09 [16:44:42.0000] devsnek: mind making a PR for bugfixes related to 1597, since you seem to be on top of them? :-) [16:45:54.0000] i'm waiting to see what people say about the execution context stuff [16:46:02.0000] but then yes i will open a pr [16:48:03.0000] awesome, thanks 2020-03-10 [00:49:08.0000] does anyone have contact details for Whymarrh Whitby from MetaMask? (please don't post them here) [08:48:02.0000] robpalme: kumavis would (they need an invite to here, too) [10:40:49.0000] I have now spoke to Whymarrh [10:40:51.0000] thanks 2020-03-11 [00:51:26.0000] it seems i'm an openjs foundation delegate now :D [00:59:27.0000] yay [12:34:58.0000] congrats devsnek! [13:05:40.0000] noice [14:16:09.0000] if anyone else here is in the Bay Area and with trouble to attend the meeting remotely, please let me know [14:22:55.0000] bradleymeck: ping [14:25:44.0000] Pong [14:55:57.0000] could someone please move me from the invited expert team to the delegate team on github [14:57:18.0000] devsnek congrats! on the team, you should probably ping one of the chairs [14:59:05.0000] akirose: perhaps? [15:00:55.0000] done [15:01:26.0000] thank you :) [15:22:04.0000] jridgewell: is logical assignment intending to go for stage 3 at this meeting? if so you should ask the editors for a review [15:22:48.0000] Do editors review at before 3 or 4? [15:25:30.0000] https://tc39.es/process-document/ [15:27:13.0000] stage 3 enterance criteria requires "All ECMAScript editors have signed off on the current spec text" [15:27:18.0000] Ahh [15:28:55.0000] Well… You want to review it? [15:29:01.0000] :wink [15:29:06.0000] πŸ˜‰ [15:29:58.0000] yes but when you're going for stage 3 affects how we prioritize it [15:30:35.0000] Yah, I meant to advance this meeting since Daniel agreed to short-circuit semantics [15:32:43.0000] I'll make an issue now [15:59:42.0000] jridgewell: are there any tests for logical assignment? [15:59:53.0000] Not yet [16:09:51.0000] jridgewell: unsure of conformance but it appears to work https://gc.gy/51673181.png [16:13:27.0000] Can you point me to the code? 2020-03-12 [17:30:22.0000] jridgewell: https://github.com/engine262/engine262/commit/a38a19dca496fcad78951fd6d8e89246c01223b0 [17:35:28.0000] Looks right [11:01:25.0000] how do i transfer a repo out of tc39-transfers? do i transfer it to "tc39"? [11:10:40.0000] shu: only the chairs can do that [11:11:05.0000] (there's instructions at the bottom of the readme on https://github.com/tc39/proposals) [11:11:50.0000] specifically, my understanding is that only the chairs can accept the transfer, and there's a time limit for accepting the transfers, so the chairs just do the whole process once it's in tc39-transfer [11:12:01.0000] sidebar: we should update tc39/proposals to list the new editors [11:12:16.0000] how-we-work maybe needs a new section for how to do chair/editor handover which lists this sort of thing [11:12:33.0000] nah that's not how it works [11:12:37.0000] no? [11:12:53.0000] to transfer to tc39-transfer, the owner of the repo is added to tc39-transfer, and then they can just summarily move it in [11:12:59.0000] right yes [11:13:11.0000] I was describing the process following that point [11:13:11.0000] and since the chairs are owners in both tc39-transfer and tc39, they just summarily move it over when they get to it [11:13:33.0000] i'm not aware of any "request transfer" feature in github [11:13:58.0000] https://help.github.com/en/github/administering-a-repository/transferring-a-repository [11:14:06.0000] > When you transfer a repository that you own to another user account, the new owner will receive a confirmation email. The confirmation email includes instructions for accepting the transfer. If the new owner doesn't accept the transfer within one day, the invitation will expire. [11:14:16.0000] that's to a user account, not to an org [11:14:22.0000] but fair [11:14:25.0000] ahh, ok [11:15:20.0000] I didn't realize that the process was different for transferring to users vs orgs [11:17:55.0000] it's v different [11:18:06.0000] to a degree that it's an annoying problem for me in my other job [11:18:46.0000] i've continually complained to github that users and orgs aren't equally privileged in the majority of workflows/features [11:23:56.0000] i continue to be mostly ignorant of how GH works [11:26:46.0000] is this like, gitizens united [11:26:53.0000] (I'll see myself out) [11:29:15.0000] is that a soft g, like gente [11:34:55.0000] it's a g like in gif [11:35:00.0000] jitizens [13:19:07.0000] MylesBorins: should I add import.meta to the agenda [13:19:16.0000] yeah probs [13:19:34.0000] cooleo will do [14:07:20.0000] akirose: there are some odd formatting issues in the welcome email, should i message you a screenshot? [14:12:21.0000] MylesBorins: i assume 15m is enough time? [14:13:16.0000] maybe 30 [14:13:18.0000] since it is a stage 4 [14:13:19.0000] we can take time back later if we don't think we need it [14:13:29.0000] πŸ‘πŸ» [14:13:31.0000] don't tempt fate [14:15:40.0000] oh god i have write perms to agenda repo now [14:16:13.0000] i'm not in front of a git atm would someone mind deleting that commit out [14:16:30.0000] sure [14:16:55.0000] i'm so used to that creating a branch by default oops [14:17:30.0000] devsnek: also "stage" is "current stage" in that table [14:17:47.0000] oh oops [14:28:31.0000] oops 2020-03-17 [11:21:11.0000] some coworkers of mine were suggesting remote coffee breaks and I realized that this is something that could potentially be done among TC39ers too :) [11:21:22.0000] with the utmost of informality, obviously [11:42:27.0000] My coworkers are doing a daily coffee meeting [11:42:37.0000] 0 work, today we talked about video games and zombie movies [11:42:56.0000] Anything to keep a human connection [12:01:55.0000] yay [12:52:19.0000] i peer behind my living room drapes and hiss at people on the street [12:54:09.0000] Shu's a cat person apparently. [12:56:40.0000] in the literal sense :p [14:12:35.0000] @chairs: https://github.com/mobile/ [14:12:56.0000] (well, @everyone, but this seems like something the chairs would find especially useful) [15:39:19.0000] I've been using the android app for a while now [15:39:30.0000] it's fantastic for non-code-reciew tasks [15:39:39.0000] review* 2020-03-18 [04:43:33.0000] yeah, I'd be happy to have a remote coffee break call if anyone is interested [08:28:44.0000] Yeah, some friends of mine have set up a monday coffee/lunch call now, more would be fun. ^_^ 2020-03-19 [15:39:58.0000] should i be PRing changes to the agenda even if it's not a proposal thing? i always forget [15:40:05.0000] (it's a PSA in this case) [15:41:46.0000] if it requires a timeslot, it requires a PR [15:41:48.0000] I would say [15:42:25.0000] ok [15:42:40.0000] (s/a PR/an agenda PR/ I mean, of course) [15:43:46.0000] right, agenda PR 2020-03-20 [00:51:55.0000] typically the guideline has been, you only ever need to make a PR within the 10 day deadline, but it's nice to make one if people need to be notified [11:42:09.0000] ah i thought the deadline had already passed [11:42:36.0000] my perception of time has completely gone 2020-03-22 [11:39:48.0000] anybody know what Istvan means by ICT? 2020-03-23 [03:44:02.0000] hey folks, i have two ideas for breakout sessions [03:44:31.0000] hubs.mozilla.com -- you can walk around and talk to people, it gives a sense of physical space and is all in the browser, and zoom breakouts (needs to be done by a moderator) [03:44:41.0000] any thoughts about this? [03:44:51.0000] also, what do you all think about a "dinner" session? [06:35:51.0000] I do think a more informal non-moderated hubs like approach would be better [09:34:16.0000] ystartsev: by dinner session do you mean actually eating on VC? [10:04:24.0000] shu: I'd guess more it is a debriefing opportunity and opportunity to revisit things that might have needed offline discussion. [10:04:54.0000] is that what the dinners usually are? :upside_down_face: [10:05:19.0000] shu: thats what I've used them for previously [10:12:51.0000] shu: you grab a bottle of wine [10:12:56.0000] and get on a video call ;) [10:13:13.0000] we did this with a few friends of mine recently, we all cooked and chatted. worked surprisingly well [10:13:20.0000] naturally you don't have to eat on camera [10:13:26.0000] but yeah thats the idea [10:13:26.0000] i have some concerns about this scaling up [10:13:29.0000] sounds great smaller scale though [10:13:39.0000] so, i think that is where hubs comes in [10:13:47.0000] because its basically a proximity chat room [10:14:01.0000] ah, dinner session on hub [10:14:11.0000] the other thing we can do is zoom's breakout rooms but that doesn't allow you to wander as easily i think? [10:14:22.0000] i don't have much experience with that so i want to do a test session to see how it goes [10:14:35.0000] also, totally open for other ideas [10:17:28.0000] hubs seems like worth a try [10:19:14.0000] hubs looks so neat why have I never seen this before [10:21:04.0000] ystartsev: do you know what the discord bot does? [10:51:24.0000] this island for the room i created is kinda small [10:51:30.0000] ystartsev: how do i get a bigger island [11:01:19.0000] +1 to trying hubs [14:14:16.0000] shu there are other rooms in the "change scene" [14:14:20.0000] im also playing around with it [14:21:20.0000] I thought shu was playing Animal Crossing for a second there [14:21:51.0000] nah still on nioh 2 [14:22:19.0000] did you play sekuro? [14:22:22.0000] sekiro? [14:22:30.0000] i think its the second one.. [14:24:32.0000] too hardcore for me but it's beautiful to watch [14:28:21.0000] ystartsev: is there a hub room we could all join, to try it out? [14:29:00.0000] ystartsev: yes i'm a big souls-like games fan, i've played all from software games since ds1 [14:30:10.0000] yeah we can [14:30:51.0000] just a sec, need my headphones [14:31:34.0000] hub.link/nnzeeVQ [14:31:43.0000] nice shortlink [14:32:30.0000] ystartsev: i can hear you but looks like you can't hear me til i pick an avatar [14:32:36.0000] yes, possible [14:32:41.0000] i can read your text though [14:32:53.0000] the avatars are horribly ugly [14:38:53.0000] oh wow rooms can be created from like [14:38:57.0000] pretty much anything [14:40:00.0000] the outdoor meetup scene looks pretty useful for our case [14:40:39.0000] which one is that? [14:40:45.0000] yeah the bigger the space the better for us [14:40:47.0000] https://hubs.mozilla.com/spoke/projects/new?sceneId=RGZEYPY [14:40:55.0000] its a demo scene in the spoke creator [14:41:05.0000] but it has a panel and a huge open area [14:41:11.0000] lol amazing [14:41:35.0000] didnt realize it was so huge 2020-03-24 [20:45:26.0000] if anyone here uses discord, i'm making a js community discord server, hit me up for the invite link 2020-03-25 [13:05:55.0000] hey all [13:05:56.0000] I'm in the zoom if anyone wants to tech check [13:06:15.0000] /me realizes maybe posting that wasn't the best idea, alas. [13:07:49.0000] taking care of logging scrub 2020-03-27 [17:04:31.0000] ljharb: so about https://github.com/tc39/proposal-atomics-wait-async/issues/28 [17:05:28.0000] ljharb: jridgewell has now convinced me in the status quo, namely that validation errors *should* return early; trigger finger was too quick on making the agenda PR. i imagine no issues with deleting the item without a PR [17:05:56.0000] no, there'd be no issues with that, but i'm not sure if that's true [17:06:24.0000] axel's article is fine advice for userland, and something i tend to follow as well, but the explicit decision (after that was posted) for `async function` was that it's zalgo to have sync errors from an async function [17:06:42.0000] eg, it should be impossible for an `async function` to synchronously throw under any circumstances [17:07:31.0000] also `Promise.all()` rejects, it does not throw [17:07:48.0000] that's a pretty clear precedent for "all errors of any kind only ever reject" [17:08:45.0000] justin has graciously provided counterexamples that it does [17:08:49.0000] Promise.all.call({}, [1, 2, 3]) // => Uncaught TypeError: # is not a constructor [17:08:55.0000] hm [17:09:05.0000] it's inconsistent with the ES6 ones, true [17:09:07.0000] you may argue that it's somehow a categorically different kind of validation error [17:09:17.0000] i'd say it kind of is [17:09:27.0000] i'd say i disagree :) [17:09:35.0000] in this case tho, it's because it can't know what kind of promise to create without a constructor [17:11:00.0000] OTOH webidl agrees with you and disagrees with me [17:11:42.0000] it seems strange if `waitAsync` can't be implemented with an `async function`. [17:15:45.0000] i don't understand what that means [17:15:52.0000] like you can't self-host it with an async function? [17:17:13.0000] (why is that weird? i'm a novice at actual software engineering with async features) [17:17:22.0000] yeah that's what i meant [17:17:34.0000] i think it's weird if a promise-returning function can't be self-hosted with the syntax for a promise-returning function. [17:18:36.0000] i see [17:18:40.0000] right, ok [17:20:18.0000] ljharb: okay, i need some time to digest. i don't really have skin in the game, so i'm kind of see-sawing [17:20:24.0000] fair enough [17:20:33.0000] i can see where the promise subclassing error is just categorically different [17:20:48.0000] and that since webidl as a matter of course converts all exceptions to rejected promises [17:20:55.0000] alignment with that seems most useful [17:25:07.0000] I think following web API's practices would be good [17:25:27.0000] My position was a weakly held "promise returning functions _could_ sync throw" [17:26:00.0000] But looking through every example I could think of, the only ones I could find were the Promise constructor's static methods [17:26:27.0000] I'd accept that's a 1-off exception :drum [17:26:31.0000] I'd accept that's a 1-off exception :drum: [17:26:45.0000] Agh, my pun is ruined. [17:29:53.0000] id say the errors should be async [17:30:04.0000] they're validating the arguments right [17:30:26.0000] I can maybe just barely see the argument for sync throw with the receiver being invalid [17:30:31.0000] but I'd rather that was async too [17:33:29.0000] yeah, my impression was definitely that the webidl convention is pretty universal in modern js [17:34:14.0000] it's also what node does, at least for `fs.promises` [17:35:11.0000] if we were to deviate here I would expect the justification to be something specific to atomics, but I don't think there is such a reason [17:38:03.0000] btw, in case anyone didn't get the "zalgo" reference, it's https://blog.izs.me/2013/08/designing-apis-for-asynchrony [17:40:21.0000] Facebook apparently replaces promises with fake promises that can resolve without waiting a tick [18:06:46.0000] great, thanks for all the datapoints [18:07:03.0000] will turn the errors async and ask for consensus for it [18:07:56.0000] incidentally how do folks feel about a Promise introspection API for the power uses that want to do something synchronously with Promises? [18:08:01.0000] domenic pointed me to a previous iteration: https://github.com/jamiebuilds/proposal-promise-prototype-inspect [18:08:45.0000] so much nope [18:09:59.0000] the demos are like literally the antithesis of the design of promises [18:10:35.0000] that promises being non-introspectable is central to its design? [18:10:39.0000] i missed that [18:10:57.0000] zalgo again [18:11:14.0000] yes, it shouldn’t be possible to observe the result synchronously [18:11:23.0000] if you want to do that just don't use promises [18:11:26.0000] so it's a slippery slope argument, that it'll enable that use case? [18:11:40.0000] is there any other use case [18:12:18.0000] the repo seems entirely focused on "the promise is fulfilled but you don't want to wait a tick to get the result" [18:12:30.0000] well, the current design of Atomics.waitAsync misses an optimization opportunity because mixing sync and async is a no go, and introspecting promises synchronously is no go [18:12:46.0000] if there were a way to do the latter, if that's somehow more palatable than the former, that'd re-enable that optimization opportunity [18:12:52.0000] optimization where you don't have to wait a tick? [18:13:01.0000] right [18:13:06.0000] what's the optimization? [18:13:12.0000] right the design of promises is that you always have to wait a tick [18:13:28.0000] https://github.com/tc39/proposal-atomics-wait-async/blob/master/SYNC-RESOLVE.md [18:13:56.0000] basically, the point of the wait API is a building block for efficient mutexes in userland [18:14:01.0000] waitNonblocking seems fine to me [18:14:10.0000] like i said, the solution is to not use promises [18:14:15.0000] it... can't not use promises [18:14:18.0000] devsnek: waitNonBlocking returns a promise [18:14:20.0000] that is the whole point of it [18:14:25.0000] oh [18:14:29.0000] also the name is out of date, it's waitAsync now sorry [18:14:31.0000] well [18:14:35.0000] but anyway the point of the API is a conditional wait [18:14:36.0000] Atomics.tryWait [18:14:41.0000] or something [18:14:50.0000] i'm not sure what that means [18:15:01.0000] it exits out if it would block [18:15:11.0000] and then you can go do other things or call the waitAsync function [18:15:19.0000] ah but whether an agent can block or not is a static property of the agent. the main thread can't block [18:15:31.0000] it's not that the user is choosing to block or to get a promise, it's that there's no choice [18:16:00.0000] can you not just do Atomics.read, and then a compare, and then Atomics.waitAsync? [18:16:03.0000] it somehow doesn't always return a promise [18:16:11.0000] Bakkot: yep, that's the workaround at the end [18:16:14.0000] oh, cool [18:16:36.0000] that seems fine to me in honesty; I would not expect that to be a significant performance difference [18:16:37.0000] Bakkot: that's probably just fine in practice 99% of the time. there's a TOTCTOU problem so you might get really surprising degraded mutex performance once on a blue moon [18:16:59.0000] Bakkot: agreed, i don't plan to change it, just got to thinking about it again [18:17:32.0000] the weirdness is mainly that it *feels* weird to have a conditional wait API that's supposed to "fail fast" and signal when you don't need to wait, but for the async version, you can't observe that signal until the microtask checkpoint [18:17:42.0000] at which point, you'd probably already waited a while [18:18:06.0000] i guess its worse for the web since it has the big render cycle thing to deal with [18:18:09.0000] the TOTCTOU problem is there for atomics.waitAsync too, yeah? nothing prevents the value from changing out from under you immediately as soon as the promise resolves, before you have had time to read from it? [18:18:32.0000] shu anyway the alternative is, you return either `{ fast: true, value: value }` or `{fast: false, promise: promise }` [18:18:44.0000] and then the user switches on `fast`, and awaits the promise if they got one [18:18:55.0000] Bakkot: ah good point, the problem is there for the entered-the-wait-queue path as well [18:19:04.0000] but i don't think in practice, once a thread is woken [18:19:11.0000] you care about what the value of the futex location is [18:19:40.0000] Bakkot: yeah, that also feels kinda gross, so status quo seems all right for now [18:19:42.0000] once atomics.read has returned the right value, you also don't care, right? [18:20:03.0000] you do, because you want the "the read value is the right one, now enter the wait queue" to be an atomic action [18:20:13.0000] in case there's a lot of contention, for instance [18:20:40.0000] if the value read is the right one, why are you entering the queue? [18:20:51.0000] that's the futex api, you enter the wait queue when *addr == val [18:21:43.0000] wait ok correction. why is the thing you would do after Atomics.waitAsync has fulfilled successfully any different from the thing you would do after Atomics.read has returned the value you were looking for? [18:22:06.0000] (it has been a while since I did low-level multithreading, sorry) [18:22:15.0000] because the thing you do next is entering the wait queue [18:22:18.0000] which should be atomic [18:22:29.0000] oh after it fulfills [18:22:30.0000] nvm [18:22:36.0000] Bakkot: the canonical example is something like, you have a tri-state mutex: 0 == unlocked, 1 == locked, 2 == locked and contended [18:22:54.0000] Bakkot: if there's contention, you don't want to immediately block the thread and wait, you want to do that if there's contention [18:23:22.0000] that last message has a typo presumably, both of your branches are "there's contention" [18:23:49.0000] oops, if there's *no* contention you don't want to immediately block [18:24:29.0000] sounds like we need futures [18:24:33.0000] Bakkot: so if the state is != 0, you wait only if the state is already == 2, or successfully compxchg the state from 1 to 2 [18:24:56.0000] otherwise, sometimes it gets "fast unlocked" in the interim and you just acquire the lock [18:25:57.0000] so the futex wait call is on that state == 2 [18:27:14.0000] does the TOTCTOU make sense now? [18:27:21.0000] still thinking through it [18:27:41.0000] Bakkot: https://eli.thegreenplace.net/2018/basics-of-futexes/ [18:27:46.0000] search for "simple mutex" [18:27:50.0000] there's a nice commented code snippet [18:30:35.0000] this snippet seems like you could implement it just fine using Atomics.compareExchange + the promise-based Atomics.waitAsync (in place of the sleep) [18:31:50.0000] I guess the point is that you want to return early if it has been unlocked _between_ your compare-exchange and your call to waitAsync? [18:32:05.0000] this being the "fast unlock" thing [18:32:21.0000] right [18:32:25.0000] where the cmoment says "Note that it's not necessary to loop around this syscall" [18:32:38.0000] the loop in JS land with waitAsync is waiting until the microtask checkpoint [18:32:59.0000] which... might be short, might be long, who knows? app dependent [18:35:08.0000] If the syscall was guarded on `if (Atomics.read(atom) != 0) {`, would that not do the thing you want? [18:35:42.0000] /me thinks [18:37:44.0000] no, i don't think so, you can imagine some scheduler that executes that line [18:37:49.0000] then basically parks that thread [18:38:14.0000] in the meantime 2 other threads do their locking/unlocking thing, and by the time you resume the first thread, you have 0 again, right? [18:39:24.0000] ah [18:39:24.0000] yeah [18:39:25.0000] ok [18:39:32.0000] i don't think it's possible to fix in userland [18:39:37.0000] but the chances of failure are exceedingly small [18:39:50.0000] and "failure" just means extra long to acquire a lock, not deadlock or anything [18:42:21.0000] yeah [18:43:20.0000] and the case it comes up is specifically where someone has unlocked your futex between the time you looked and the time you went to enter the queue, which is pretty much the immediate next operation you are doing [18:43:44.0000] having the extra microtask tick on the main thread in that case seems ok [18:45:17.0000] this is definitely an Atomics-specific reason to be able to return early sometimes, though; if we wanted to address it I think having your API return sometimes-sync sometimes-promise (ideally wrapped, as in my example above) would be a better fix than introducing a general-purpose promise introspection utility [18:48:21.0000] right [18:48:47.0000] Bakkot: yeah, that sounds very reasonable [18:49:18.0000] need to stew on whether we want to return a wrapped thing [18:49:40.0000] it's kinda unergonomic to not be able to write `await Atomics.waitAsync(...)` but shrug [18:50:08.0000] hmm, yeah [18:50:23.0000] I guess it would be ok for it to not be wrapped, given that await can be passed a non-promise value [18:50:28.0000] I dislike that fact but it is what it is [18:51:50.0000] though, actually, does that `await` not introduce an additional microtask tick in the case that waitAsync returns a promise? [18:52:04.0000] it doesn't [18:52:13.0000] though it used to [18:52:15.0000] ahh [18:52:16.0000] cool [18:52:28.0000] that was the "await optimization" thing the chakracore people brought at some point [18:52:38.0000] changed it to just do Promise.resolve(v).then(resume) [18:54:26.0000] The await optimization took it from 3 ticks to 1 tick. [18:54:49.0000] But using `await` always ticks. [18:55:14.0000] The only way a sync-promise would work is if you did `Atomics.waitAsync(...).then(syncStuff)` [19:03:07.0000] shu: I guess I am convinced that a not-wrapped value would be OK. I would maybe prefer `{ fast: true, value: 0 }` or `{ fast: false, value: promise }`, so that you don't have to do the typeof check and can still do the handy `await Atomics.waitAsync().value`. [19:03:15.0000] but, also, I don't think this necessarily needs solving [20:07:49.0000] i think wrapped is the way to go if we wanna solve it, but yeah i agree i’m not sure this needs solving [10:55:50.0000] Btw, I know I missed this meeting's deadline (not thru laziness! we just came up with the idea too late!), but putting this out there in prep for the next meeting: https://github.com/tabatkins/proposal-item-method [10:57:21.0000] hopefully we can dedicate 30-40m to bikeshedding the name [10:58:29.0000] devsnek: fortunately the justification for this one is in many ways tied to the name being exactly `item` [10:58:34.0000] which is quite nice [10:59:24.0000] why not at() [10:59:32.0000] read the readme [11:00:04.0000] tldr is "to match the DOM" [11:00:16.0000] i think we've been all right about bikeshedding recently [11:00:32.0000] we don't *have* to match the dom though [11:00:42.0000] we don't have to do a lot of things [11:00:46.0000] not that i disagree with the motivation [11:01:52.0000] devsnek: we don't have to, but the advantage of matching is not just for consistency but that it allows the DOM array-wrapping apis to avoid some magic [11:04:08.0000] i like the proposal [11:04:16.0000] just wanted to point out it was technically not imperative [11:04:21.0000] ah, yeah [11:05:31.0000] yeah it's not imperative, just, there's a strong built-in bias towards one particular name, which helps avoid bikeshedding [11:07:24.0000] TabAtkins: fwiw it looks like mootools does _not_ have `.item`; it was the largest offender on fragile builtin overrides pattern, to my knowledge. so that's hopeful. [11:07:32.0000] Nice. [11:07:56.0000] smooshIntoCollectionIndex(n) [11:08:02.0000] Prototype / Ext also had issues in the past (goes off to check) [11:09:05.0000] they both do not have that method [11:12:24.0000] double nice [11:12:43.0000] re: bikeshedding; I [11:12:45.0000] lol [11:13:00.0000] clearly we need to add a new syntax [11:13:09.0000] japanese quotation marks [11:13:19.0000] re: bikeshedding; I'm one of the people who've desperately wanted negative indexing as well, so *any* name would make me happy on those grounds, but yeah, using exactly .item() would make me even happier [11:13:49.0000] there was a proposal from someone at some point for indexing/stepping syntax [11:13:59.0000] might've been on the discourse [11:14:26.0000] API would be simpler / provides benefits that can be backported cheaper [11:14:37.0000] yeah i agree [11:17:55.0000] Bakkot/bradleymeck: thanks, added the info to the proposal [11:19:52.0000] btw, am I right in my findings that the TypedArray superclass isn't publicly exposed under any name, and so the way to add to all typed arrays' prototypes is indeed `Uint8Array.__proto__.prototype.item = item;`? [11:20:38.0000] TabAtkins: use Object.setPrototypeOf as Deno/Node don't guarantee __proto__ anymore, but yes [11:21:34.0000] getPrototypeOf* [11:22:23.0000] i wonder if we should have an Iterator.prototype.nth [11:22:37.0000] -1th [11:22:41.0000] probably not since we can't really lower it for perf [11:22:46.0000] but its nice in rust [11:23:39.0000] Anything that implies random access over an iterator is probably bad. [11:24:28.0000] You want to be more explicit that you're first discarding N-1 values from the iterator, then taking the next one. [11:24:39.0000] there was an interesting discussion along that line in the proposal [11:24:46.0000] about giving an index in the map/etc functions [11:24:56.0000] That can def be worthwhile to build into the Iterator protocol under an easy name, it just needs to be clear in its semantics. [11:25:05.0000] yeah rn you'd do skip(n).next() i guess [11:25:14.0000] yeah [11:25:17.0000] or skip(n - 1) i guess [11:25:26.0000] seems fine to me [11:25:32.0000] no, skip(n) is correct [11:25:36.0000] that's plenty explicit [11:25:54.0000] if you want the fifth item you'd skip four and take one [11:26:16.0000] where's the zeroth item? [11:26:26.0000] you filthy 1-indexer [11:26:28.0000] skip(0) is no-op [11:26:32.0000] exactly [11:26:37.0000] its the number of items to skip [11:26:43.0000] Yes, I know. [11:26:57.0000] I'm saying that ".nth(0)" is "skip 0 items, get the next one" [11:27:18.0000] oh i see what you mean [11:27:22.0000] because the 5th item is at index 5, and thus has five items before it [11:27:26.0000] yeah by fifth item i meant [11:27:31.0000] lol [11:28:01.0000] *violent agreement* [12:00:53.0000] what if it was named nst [12:03:21.0000] shu: what if you were named nst [12:03:32.0000] let's compromise and name is nnd [12:03:52.0000] n2d sgtm [12:17:09.0000] `nnd` -- takes a number but rounds it to the nearest integer ending in a 2 first [12:17:46.0000] proposal to add rounding mode flag to Math.round [12:20:45.0000] oh wow [12:20:47.0000] https://upload.wikimedia.org/wikipedia/commons/8/8a/Comparison_rounding_graphs_SMIL.svg [12:20:51.0000] what a delightful chart [12:21:30.0000] this svg has hover effects [12:21:33.0000] I did not know you could do that [12:22:08.0000] neither did i [12:29:25.0000] Oh yeah, hover is great [12:29:40.0000] I don't think *this chart* uses them very well; it's still nearly unreadable when you hover one, but hey [12:34:30.0000] i'm impressed by the number of things and the different colors [12:47:57.0000] (node still guarantees __proto__ by default, what flags do is different) [12:48:48.0000] TabAtkins: so, aside from the DOM pushing a specific name, what semantics does that push for, specifically around validation errors/exceptions and edge cases? [12:49:26.0000] That's a good question and I'll figure it out and document it [12:50:07.0000] TabAtkins: because i'm only mildly annoyed by the web predetermining the name, but if they predetermine other semantics that don't align with what would actually be conventional for JS, i'm a lot more annoyed [12:50:50.0000] I highly suspect that the more detailed semantics aren't important to compat here [12:52:47.0000] that's ideal :-) [12:54:51.0000] ljharb: so i think a uniform way to do relative indexing for indexable data is the high-order bit; if the web compat bit cost is naming, that sounds pretty win-win to me [12:57:37.0000] TabAtkins: NodeList's item does not support negative indexes [12:58:08.0000] changing that behavior seems like it might be breaking [12:59:12.0000] I doubt that. We'll see! [12:59:33.0000] Before this ships we'll probably need to instrument and verify. [12:59:40.0000] if not that would be ideal [13:00:30.0000] Not hard to measure how many pages pass negative numbers to it right now [13:01:30.0000] great [13:02:13.0000] it is easy to imagine someone doing `i = list.length - 1; do { e = list.item(i); doThing(e); --i; } while (e != null)` or whatever [13:02:23.0000] people write all sorts of crazy loops [13:02:32.0000] what does NodeList's item do now when passed a negative number? [13:02:48.0000] returns `null` [13:03:11.0000] (nb not `undefined`, which is probably also something which would have to change) [13:09:05.0000] ah [14:03:14.0000] shu: oh sure, for naming that's why i'm only mildly annoyed [14:03:35.0000] (fwiw i do consider the feature useless without support for negative numbers) [14:07:41.0000] Yeah, DOM stuff always returns null, another Java legacy. [14:08:04.0000] But since most people test for null with either a `== null` or `!` check, switching to undefined has a good chance of being safe. [14:09:02.0000] honestly this seems like arguments to not use `.items` [14:09:10.0000] er `.item` [14:10:36.0000] Unless they prove to be breaking, they're not. And the point of me introducing this is to try and get .item() specifically. [14:10:59.0000] In the worst case, we just don't upgrade the legacy interfaces. [14:11:05.0000] And JS is free to do whatever. [14:11:11.0000] i mean you'd have to prove no code does `=== null` [14:11:31.0000] or yeah we can not make the web use the new behaviour [14:11:32.0000] No, we just have to have reasonable assurance, and not see reported breakage in dev/beta channels. [14:12:08.0000] seems like a lot of trouble for no payoff [14:13:17.0000] The payoff is I get to quit writing `[...document.querySelectorAll("a")].map(foo)` [14:13:30.0000] becasue NodeList is a freakin' Array now [14:14:11.0000] wait do you actually want to replace NodeList with Array [14:14:21.0000] (Or rather today I always do a `function findAll(sel) { return [...document.querySelectorAll(sel)];}` at the top of my projects [14:14:42.0000] No, with ObservableArray, which is a proxy around Array that lets us still intercept get/set/etc. [14:14:51.0000] Domenic wrote it up and got it into WebIDL just a little bit ago. [14:14:52.0000] I have never seen someone spell that function anything other than `$$` [14:16:18.0000] so you want it to be called .item so you don't have to worry about whether you're dealing with an ObservableArray or an Array [14:16:25.0000] or something else [14:22:40.0000] TabAtkins: you should already be writing `Array.from(document.querySelectorAll('a'), foo)` :-p [14:23:00.0000] god why [14:23:05.0000] so you don't create an intermediate array [14:23:20.0000] Array.from's mapper function is a godsend, i use it allllll the time [14:23:37.0000] devsnek: ObservableArray is a proxy over Array, so it's not a matter of "which one you see" - as far as the author is concerned they're getting an Array. [14:23:41.0000] something something premature optimization [14:23:58.0000] TabAtkins: well in theory ObservableArray could be a subclass and a proxy [14:24:01.0000] see the doc for exploration of some of the alternate choices and why i prefer not to have them [14:24:04.0000] the iterator protocol is slow Β―\_(ツ)_/Β― [14:24:06.0000] not just a proxy [14:24:07.0000] including that one in particular [14:24:10.0000] Bakkot: but yeah fair [14:24:21.0000] ljharb for arrays? is it really? [14:24:38.0000] Bakkot: NodeList isn't an array [14:24:45.0000] yah it's fakey fake fake [14:24:47.0000] s/arrays/nodelists/ [14:24:57.0000] Bakkot: i'm sure it's optimized for the common use cases in modern engines, the ones where perf matters the least [14:25:08.0000] i wouldn't describe iterators as slow [14:25:19.0000] what i also personally like is, not having to rely on `.map` being there [14:25:21.0000] but i wouldn't describe them as blistering fast either [14:27:17.0000] ljharb yeah I mean if you observe that you have performance issues I am all for using whatever hacks are necessary to become fast, though usually that means using imperative loops rather than function style [14:27:26.0000] if you have not yet observed that, keep your code readable [14:28:16.0000] https://twitter.com/devsnek/status/1243586726976724992 [14:31:49.0000] lul [14:32:10.0000] Bakkot: i find the array.from example readable personally [14:32:15.0000] devsnek: lol [14:32:34.0000] readable because you know the signature of Array.from [14:33:08.0000] I didn't know about that second arg [14:33:29.0000] TabAtkins: your site is making me dizzy [14:33:41.0000] the homepage? [14:33:46.0000] ya lol [14:33:58.0000] lol [14:34:38.0000] my website is literally text/plain though so i can't really throw shade [14:34:39.0000] ljharb it's fine if you and all future readers of the code can be expected to know about the second argument, but I don't think people should know about it. people should learn about `Array.from()` with one argument, and learn about `map`, and those compose naturally, and then there is no reason to ever learn this third thing (Array.from takes a second argument). [14:35:27.0000] (unless they start getting into microoptimization, of course, but that's gonna need to be backed up with bechmark data for their particular codebase and userbase) [14:35:28.0000] i don't think it's unreasonable to expect people to know about something built into the language, that's not esoteric [14:35:37.0000] it should be esoteric [14:35:46.0000] because there is no reason to learn it [14:36:18.0000] in theory an engine can combine Array.from().map [14:36:35.0000] if the map argument is pure at least [14:36:37.0000] if there's no reason to learn it, then why was it shipped [14:36:56.0000] ljharb do you also use the second argument to Array.p.map? [14:36:56.0000] devsnek: only if the mapper doesn't access or detect the third argument [14:37:09.0000] like i said, if its pure [14:37:15.0000] we ship plenty of things we don't want people to learn, what [14:37:19.0000] devsnek: it can be pure even if it accesses it [14:37:19.0000] do you also think it is reasonable to expect them to learn that? [14:37:24.0000] Bakkot: no, true enough [14:38:01.0000] shu: are you telling me i should've bother learning String.prototype.blink [14:38:33.0000] there's a lot of reason to learn that over second argument to map or from [14:38:40.0000] - street cred [14:38:40.0000] ...what's the second argument to map() [14:38:46.0000] ok but the `this` argument to .map was added in 2009, before arrows, and before .bind was common [14:38:48.0000] thisArg [14:38:53.0000] - historian cred [14:38:57.0000] oh, to the map callback [14:38:59.0000] phew [14:38:59.0000] Array.from's mapper arg was added in 2015, along with array spread [14:39:03.0000] oh no wait i see [14:39:08.0000] so what was the rationale for it, if it's not worth learning? [14:39:10.0000] TabAtkins: and the callback itself takes (item, index, array) [14:39:33.0000] i think you mean (element, index, collection) (EIC, still waiting for "haltToken") [14:39:41.0000] lol [14:39:51.0000] can confirm that's how brendan himself teaches it [14:39:57.0000] `(element, index, collection, signal)` [14:40:12.0000] I don't understand how you could replace these not-an-arrays with `ObservableArray` [14:40:44.0000] well if it only breaks less than .0003% of the web or whatever chrome's metric is [14:40:55.0000] We'd have to add every method that the no-an-array has to `ObservableArray` or `Array`? [14:41:08.0000] jridgewell: There's precisely one. [14:41:10.0000] .item() [14:41:20.0000] For all the not-an-arrays? [14:41:24.0000] For a lot of them, at least [14:41:28.0000] NodeList, StyleSheetList [14:41:35.0000] ljharb: the reason for the mapper function for Array#from was it enables easier array subclassing [14:41:53.0000] (ugh) [14:41:55.0000] Ok. [14:42:03.0000] shu: how? [14:42:04.0000] (does this mean `e, i, c, h` is the `s t a b` of JavaScript) [14:42:16.0000] So because `Array` would now conform the the API provided by `NodeList`, it wouldn't matter that we now returned an array... [14:42:18.0000] shu: you mean like a subclass doesn't have to override `.map`, just `static from`? [14:42:27.0000] Would there still be the perf cliff? [14:42:45.0000] Eg, a live `NodeList` [14:42:48.0000] jridgewell: I mean, we still need the proxy for things that are live. [14:42:49.0000] ljharb: https://github.com/tc39/notes/blob/master/meetings/2013-01/jan-30.md#revising-the-array-subclassing-kind-issue [14:43:24.0000] shu: lol that says there's a thisArg, but there isn't one [14:43:32.0000] but well, now i feel dirty, because one of my favorite parts of the language was created to enable a dumb and inconsistent subclassing model [14:44:01.0000] no i think the lesson here is just all artifacts exist historically [14:44:33.0000] fair [14:44:42.0000] i retract my implication that existence proves usefulness [14:44:50.0000] (but i still find this one useful) [14:45:53.0000] rkirsling: yes [14:45:58.0000] yeah i think for computers especially after some time the original motivations don't really matter [14:46:04.0000] > existence proves usefulness *cries in abstract equality* [14:46:06.0000] TabAtkins: :D [14:46:11.0000] (i still dont' understand what the `s t a b` mean, either individually or collectively) [14:46:29.0000] it's `s t` and `a b` separately but adjacent [14:46:41.0000] which comically forms a word [14:46:54.0000] if you try to explain Lenses to me here in IRC i will fight you [14:47:26.0000] I absolutely will not πŸ˜‚ I actually only understand it at a very high level myself [14:48:09.0000] yeah i know roughly how to use it, but no clue whatsoever how the abstraction works [14:48:33.0000] i.e. "pure FP decided it wanted in on the property access thing too" [14:48:35.0000] which annoys me becasue people complain about monads and, like, they're trivial, so i'm not sure if lenses are in the same boat and i haven't hit the insight yet, or they're actually complicated and it's okay [14:49:02.0000] that kind of functional programming is basically that kindergarten game where you need to find the right shaped hole for objects [14:49:27.0000] and then being very proud you stacked several objects together and put it into a novel shaped hole [14:50:03.0000] isn't that kind of the whole idea of naturality in category theory though? :p [14:50:13.0000] basically yeah [14:51:03.0000] someone was really upset that we put in optional chaining instead of a method on properties that returns Option [14:51:06.0000] took me an embarrassingly long time to figure out you were talking about lenses and not pokemon [14:51:33.0000] as much as i dunk on pokemon, pokemon is orders of magnitude more beneficial for society than category theory [14:51:40.0000] ( https://bulbapedia.bulbagarden.net/wiki/Same-type_attack_bonus ) [14:51:48.0000] shu: ouch [14:52:06.0000] Bakkot: fascinating [14:54:04.0000] that Baez guy is all about applying category theory to save the planet though [14:54:27.0000] here's hoping he finds success 🍷 [14:57:41.0000] i think mathematicians are exempt from my hot take [14:57:54.0000] πŸ˜† [15:32:19.0000] agendas repo seems like it should maybe be read-only for non delegates, if that is a possibility? [15:32:53.0000] +1 [15:34:42.0000] is it not? [15:35:04.0000] evidently not, no [15:35:17.0000] i wasn't able to modify it until i became a delegate [15:35:22.0000] i was in the invited experts team before that [15:35:25.0000] oh, sorry, I meant issues as well as the code [15:35:42.0000] only for a 24 hour period as a time [15:35:48.0000] all issues are open for all on github [15:35:56.0000] huh [15:36:14.0000] bleh [15:55:57.0000] :( [16:16:24.0000] Bakkot: you're saying "must implement as specified" is weaker than "must not implement except as specified"? like, the former would still allow for bonus params or something? [16:17:12.0000] er sorry "must not extend except as specified" [16:17:43.0000] rkirsling: yes [16:17:48.0000] I see [16:17:50.0000] and also in the case that 402 is not active it says "the following is used", rather than "the following must be used" or whatever [16:18:17.0000] wait but "is" sounds even more unwavering to me than "must" [16:21:25.0000] sorry, the "it" in that sentence is "BigInt.prototype.toLocaleString" [16:21:54.0000] so, yes, that's my point - the current BigInt.prototype.toLocaleString does not read as a strong of a requirement as the forbidden extensions does [16:24:03.0000] alright [16:25:59.0000] I see [16:26:21.0000] do you agree that it seems like an unintentional omission though? [16:27:33.0000] can't we just say "extensions to builtins that are otherwise specified in 402 are forbidden" [16:27:38.0000] or something along those lines [16:27:42.0000] bikeshedding needed [16:28:15.0000] yeah it might be ideal to not have to keep maintaining the list [16:30:15.0000] it seems like a spec bug, but still a normative change [16:30:26.0000] i also think it would be good to avoid the list [16:30:41.0000] (especially since you can already grep for "402" in the spec to find all those extension points) [16:31:55.0000] rkirsling yes it's definitely accidental; this is just a process point [16:32:15.0000] we can resolve it in two minutes in plenary [16:37:48.0000] cool [16:39:29.0000] Bakkot: Added a list of upgradeable interfaces, and a (comprehensive afaict) list of the changes from current behavior with an exploration of the possible breakages that could result. [16:39:38.0000] thanks for the push to do it [16:39:39.0000] nice! 2020-03-28 [17:54:36.0000] ljharb: so you're going to present it then? :p [21:36:18.0000] rkirsling: you are most welcome, i just didn't want to voluntell anyone [21:45:21.0000] oh lol [21:45:47.0000] I'm more than happy [21:46:01.0000] it's true that I made the PR because I felt certain it was editorial [21:46:28.0000] but it's simple to argue for, particularly if I already have folks agreeing [21:55:24.0000] i mean, i can't imagine anyone will do anything except conent [21:55:25.0000] *consent [21:55:31.0000] but, technically, i think it's normative [21:55:53.0000] and we all know https://www.youtube.com/watch?v=hou0lU8WMgo [21:57:36.0000] :nod: [22:51:48.0000] s/best/only/ [22:52:24.0000] ^ that is also technically correct [22:53:05.0000] the best kind of correct [22:53:57.0000] GOTO HEAD~3 2020-03-29 [18:43:59.0000] hey, remember that "we should write a blog post about Annex B.3.3 idea"? [18:44:09.0000] I just spent my whole afternoon doing that for some reason [18:44:17.0000] but I don't have a blog :P [18:44:31.0000] so here's a gist: https://gist.github.com/rkirsling/d91ff18947193c22f970032b73daf952 [18:44:48.0000] please give me feedback and an idea for somewhere to publish it lol [19:31:50.0000] is Medium still the thing people use? I don't even know [19:36:57.0000] upload to gh pages using this jekyll template https://raw.githubusercontent.com/devsnek/devsnek.github.io/master/_layouts/default.html?token=ABNNHYPPFV5MUSMQQ5FXTQC6RFCDQ [19:42:29.0000] heh I suppose self-hosting would be an option [20:21:42.0000] oh or is dev.to the hotness these days, feel like I've seen that around a fair amount [20:28:46.0000] i find dev.to to just be lots of people writing inaccuracies about things [20:29:01.0000] and if you point out any of those inaccuracies you get a warning from the mods about not being constructive [20:29:53.0000] :( [20:34:52.0000] rkirsling: nice! now I can link people to this instead of having to explain it from scratch [20:34:59.0000] <3 [20:35:14.0000] just lemme house it in a place that's not a gist first πŸ˜‚ 2020-03-30 [17:18:28.0000] think I'm just gonna use dev.to since it at least supports syntax-colored codeblocks and doesn't paywall you, unlike Medium [17:18:50.0000] and then work on replacing http://rkirsling.github.io/ with something new as a separate quarantine activity, heh [17:19:57.0000] kinda wish I could guest-post it somewhere but I dunno what'd work since it's too engine-independent for webkit.org and PlayStation doesn't have a dev blog, hehe [18:33:02.0000] https://dev.to/rkirsling/tales-from-ecma-s-crypt-annex-b-3-3-56go [00:37:18.0000] @rkirsling: that was an enjoyable and horrifying article [00:47:39.0000] robpalme: :D [10:43:44.0000] i missed the hubs test, but i love the room design :-) we should make a chessboard and play! [14:32:36.0000] i missed this morning's tech test for hubs [14:32:47.0000] is the decision for hallway track hubs? [14:33:00.0000] i hope so [14:33:04.0000] when myles and a few of us tried zoom's breakout rooms, they didn't quite work as the name suggested [14:36:57.0000] shu: hubs had its own glitches but it was seemingly preferred and can be left in the background [14:37:12.0000] can't exactly leave zoom in the background [14:44:57.0000] zoom's close to being usable for what we need, but rn it's not usable at all for it [15:48:38.0000] sffc: thanks for creating all those Intl tickets on WK BZ :D now I have a checklist of things to work on [15:51:05.0000] also wow, it's kind of fascinating that `const x = true; x || = 42;` doesn't throw [15:51:45.0000] hm, that's actually an interesting point [15:52:02.0000] it can throw [15:52:03.0000] (oops, errant space in there, but you know what I mean) [15:52:08.0000] like, it shouldn't trigger a setter if it's `obj.x ||= 42` [15:52:17.0000] it can throw without triggering a setter [15:52:19.0000] but maybe it should throw if it's a const on the LHS - but then it'd be inconsistent [15:52:20.0000] it resolves the reference [15:53:49.0000] I think it would have been better we threw early errors for any assignment to a const [15:54:00.0000] But I followed the precedent [15:54:04.0000] we can't know at early error time [15:54:22.0000] actually wait can we [15:54:33.0000] we totally can [15:54:37.0000] Could have, but it'd be a huge breaking change now [15:54:38.0000] can anything shadow lexical variables [15:54:41.0000] as long as there is no`with` or `eval` [15:54:52.0000] ok so eval [15:55:05.0000] direct eval in particular [15:55:11.0000] unfortunate [15:55:23.0000] we should have just made it an error unconditionally though [15:55:30.0000] Babel had to change its const behavior to rewrite the assignments with a throw. [15:55:32.0000] jridgewell: what do you think about throwing in logical assignment if the reference is constant [15:55:40.0000] and if you had an `eval` or `with` which would have made it conditional, that would be on you [15:55:58.0000] I would like that [15:55:58.0000] also this might not have been web-compat because firefox had shipped `const` previously maybe? I forget [15:56:21.0000] i didn't think es2015 const was compatible with old firefox const [15:56:23.0000] fwiw I don't think it would be good to special-case logical assignment to const here [15:56:42.0000] yeah I'm not objecting to the simplicity of the current spec [15:56:49.0000] i don't mind either [15:56:50.0000] just slightly lamentable [15:57:00.0000] but it might be worth discussing [15:57:02.0000] it is not obviously more important than getting errors for strict-mode assignment to nonwritable variables [15:57:11.0000] I think it IS worth mentioning in plenary [15:57:29.0000] I totally forgot about it until drousso just noticed it in his own impl tests [15:57:30.0000] in a way, it's not technically wrong [15:57:42.0000] it doesn't assign [15:57:50.0000] yeah [15:58:26.0000] and it throws if it does assign [15:58:33.0000] I wonder if it would be web-compat to make assignment to const an early error [15:58:38.0000] almost certainly not, I guess [15:58:40.0000] but :( [15:58:51.0000] gotta get an assignment to const counter [15:59:02.0000] yeah i was going to bring it up :P [15:59:08.0000] devsnek: do you know about the third mutable/constant variant for variables? [15:59:12.0000] function names, in particular [15:59:20.0000] const-but-writing-fails-silently [15:59:23.0000] lul [15:59:26.0000] what a dumb language [15:59:29.0000] heh [15:59:33.0000] whenever i get annoyed with js [15:59:42.0000] i spend more time working on my toy language [15:59:57.0000] (i've been working on it a lot while we've been talking about records and tupes) [16:00:00.0000] outlets are important [16:00:03.0000] also jridgewell huge fan of this proposal :) [16:00:42.0000] are tests not required for stage 3 [16:01:11.0000] complete tests are definitely not required [16:01:15.0000] πŸ˜„ [16:01:31.0000] so implementations are expected to start working on it without tests [16:01:42.0000] i guess this is where web compat issues come from [16:02:01.0000] uh I mean the earlier the better but generally help is needed with the test262 tests [16:02:05.0000] Stage 3 generally locks the spec, which is how we know what to test. [16:02:10.0000] yeah i do think it would've bene nice to have tests πŸ˜… [16:02:18.0000] but i may have jumped the gun a bit on implementing it [16:02:37.0000] I can work on them, but it'll just be me copy pasting the `+=` tests [16:03:14.0000] do we know what has implemented logical assignment yet [16:03:14.0000] mainly happened cause i had to call "dibs" or rkirsling would've implemented it before me 🀣 (thanks again rkirsling ❀️) [16:03:26.0000] stage 3 requires a PR with some tests, doesn't it? [16:03:32.0000] just not totally complete tests [16:03:32.0000] lol I was going to do it this weekend otherwise [16:03:38.0000] devsnek i have a patch up for JSC :) [16:03:42.0000] instead I worked on upgrading ICU lol [16:03:45.0000] hasn't landed yet tho [16:03:54.0000] hm that might mean engine262 was first [16:03:58.0000] jridgewell test262 supports generating tests; might be a good place for this [16:05:46.0000] re: where web compat issues come from [16:05:54.0000] I think it's kind of the opposite of true [16:05:55.0000] Babel supports it! [16:06:12.0000] Bakkot: stage 3 requires complete merged tests [16:06:16.0000] not just some [16:06:20.0000] oh neat [16:06:27.0000] when did google drive stop doing shortlinks for the share button :( [16:06:28.0000] oh I knew that [16:06:54.0000] wawait no [16:06:58.0000] stage 4 requires that [16:06:58.0000] > During stage 3, test262 tests should be authored and submitted via pull request. Once it has been appropriately reviewed, it should be merged to aid implementors in providing the feedback expected during this stage. [16:07:02.0000] stage 3 does not require any tests [16:07:05.0000] per the process document [16:07:09.0000] tests are literally only for Stage 4: https://tc39.es/process-document/ [16:07:09.0000] oh right [16:07:11.0000] I hope not, I haven't written them. [16:07:12.0000] Bakkot: that's stage 4, sorry [16:07:15.0000] yeah [16:07:27.0000] we definitely did not have good tests in order when ?. and ?? hit Stage 3 [16:07:30.0000] it's a good signal to have them posted for stage 3 tho, altho not merged [16:07:37.0000] I have been in the habit of opening a PR with tests prior to going for stage 3 [16:07:41.0000] ...but I think we had more than zero [16:07:54.0000] for that "signal" ljharb mentioned [16:08:06.0000] like a test plan [16:08:09.0000] jridgewell i dunno if you or anyone else has written any tests, but you're welcome to use any of the ones I wrote if that'd help :) [16:08:23.0000] mine are by no means fully comprehensive tho [16:08:26.0000] oh look, speaking of which: https://github.com/tc39/test262/issues/2538 [16:08:27.0000] definitely missing some cases [16:08:29.0000] What are your tests? [16:08:45.0000] kind of think we ought to require nonzero tests open in a PR as a requirement for going to stage 3 [16:08:51.0000] often it helps think through the semantics [16:08:51.0000] jridgewell they're in the patch I have for JSC [16:09:00.0000] /me frantically starts writing tests [16:09:34.0000] not for this meeting obviously :P [16:10:12.0000] i wish more people would use the blue and yellow slides theme [16:10:14.0000] nonzero seems positive; my one counterpoint is that it's easy to write mistaken tests that way [16:10:18.0000] it works great for js stuff [16:10:38.0000] ljharb: thanks for deleting the branch too πŸ‘πŸ» [16:10:44.0000] e.g.: https://github.com/tc39/test262/pull/2411 [16:10:49.0000] Which theme? [16:11:01.0000] jridgewell: https://gc.gy/53314860.png [16:11:02.0000] devsnek: it's a github checkbox, it's automatic now [16:11:09.0000] o [16:11:11.0000] rkirsling: yep, I realized there hadn't ever been bugs filed for the last 2yrs of Intl features for JSC. There is a bit of catch-up to do ;) [16:11:29.0000] rkirsling: one would fix the tests in the PR if there's a bug discovered in the spec text, presumably [16:11:53.0000] Bakkot: oh I meant a bug due to the test having misread the spec text [16:11:58.0000] oh [16:12:15.0000] not sure why that would come up any more when going for stage 3 than 4 [16:12:49.0000] if there are bugs in the tests i will inevitably find them [16:12:55.0000] i have a slide on this in my presentation [16:12:59.0000] sffc: yeah. on the one hand, it's sad that we're so behind. on the other hand, it's lots of really awesome stuff to work on! currently in the midst of updating our minimum ICU version from 55 to 62, heh [16:13:38.0000] Bakkot: it wasn't an objection :p just a thought 2020-03-31 [17:02:40.0000] jridgewell can I assist in writing tests? [17:03:55.0000] I have 0 tests... [17:04:04.0000] How would you like to test? [17:04:08.0000] help** [17:06:51.0000] no idea lol [17:07:03.0000] just thought i'd offer, given that i already have something testable ;P [17:07:21.0000] i've never written anything test262, but am keen to learn :) [17:07:29.0000] Maybe if you could make a list of the things you think we should test? [17:07:43.0000] I have also never written a test262 test... [17:10:01.0000] aim for 100% coverage https://coveralls.io/builds/29699669/source?filename=src/runtime-semantics/AssignmentExpression.mjs [17:10:26.0000] unfortunately most of my parser is a dependency so i can't get good coverage data out of that [17:11:36.0000] it would be super ideal if you could just be like "hey, when this holds, just do exactly what = is already doing" but given that it's a totally separate operator you basically need to do all the same tests again... :( [17:12:09.0000] use ai to merge `+=` tests with `||` tests [17:13:29.0000] AI? In *my* parser? [17:13:46.0000] ljharb: is this still somewhere on the editor group docket? https://github.com/tc39/ecma262/pull/1860 [17:14:13.0000] jridgewell i'll see if I can come up with a list tonight [17:14:32.0000] drousso: are y'all able to get coverage from bytecode and stuff [17:14:39.0000] rkirsling: it's not, but i can add it [17:14:55.0000] i already have a bunch of the straightforward cases either implemented or discussed in [17:15:06.0000] devsnek i don't know, i'm a noob with JSC πŸ˜… [17:15:12.0000] i did this work partly to try to learn more [17:15:16.0000] ljharb: much obliged [17:15:23.0000] CC keith_miller msaboff [17:16:22.0000] if it can't, engine262 can do `npm run coverage` for an html which might be useful [17:17:09.0000] you could also do `./node_modules/.bin/nyc node test/test262/test262.js test/language/whatever-logical-assignment-tests**` [17:19:00.0000] lol I'm pretty sure that's just engine262 though [17:19:43.0000] oh yeah that's just to verify the tests [17:19:53.0000] to some degree [17:20:10.0000] it doesn't tell you if all the engines will pass :P [17:20:15.0000] you'd need uh [17:20:22.0000] test262-harness for that [17:39:15.0000] how does GH still not have a crying reaction [17:39:27.0000] #stifledexpressivity [17:41:44.0000] ljharb: should I update myself as the presenter for the forbidden extensions PR, if you were just hesitant to make me do it? [22:21:31.0000] rkirsling: absolutely! no need for a PR for that change either, just push a commit :-) [08:40:21.0000] what link are we using for hallway track? [08:41:14.0000] I think this - https://hub.link/bHXk2f8 [08:44:46.0000] Reminder that this chat is public. [08:45:07.0000] Only share links in the Reflector. [08:45:35.0000] this channel is private, right? only #tc39 is public I thought [08:45:39.0000] ugh [08:45:46.0000] this channel is public now too [08:46:03.0000] oooof. sorry y'all, I didn't know that changed. [08:46:08.0000] it is publicly viewable, not open to public contributions [08:46:30.0000] it's understandable, this is only the second meeting where that's the case [08:46:38.0000] ystartsev: can a new link be generated [08:46:57.0000] it's easy enough to change the hubs link if we find unwanted users [08:48:28.0000] i'm going to have to deep clean my laptop from this zoom install [08:49:50.0000] zoom added code snippets apparently [08:51:17.0000] I don't even know what that means [08:51:30.0000] in the text chat [08:51:46.0000] we might need to have a no-zoom-text-chat rule btw [08:52:05.0000] yeah, at least for the sake of my sanity [08:52:15.0000] there's already enough places to follow during a meeting [08:52:37.0000] well for the public discussion rule as well, unless note takers are going to be summarizing the text chat [08:53:17.0000] yes I understood [08:53:41.0000] where do I find the TCQ link? [08:53:51.0000] it's not in the channel topic and not in the Reflector issue [08:54:15.0000] i'm not sure [08:59:27.0000] reflector [09:07:30.0000] Is someone going to post the hubs URL to the Reflector issue? [09:17:53.0000] devsnek: yep [09:18:25.0000] apaprocki i can generate one [09:25:46.0000] its on the reflector now [09:26:29.0000] what's the idea for the hubs, are we supposed to idle there? [09:26:33.0000] or join it during breaks? [09:27:21.0000] shu: either works [09:27:34.0000] i do recommend reducing the settings so that it doesnt have the fan spinning all the time [09:28:03.0000] shu: i think idling during breaks at least allows people to start conversation in the way hallway track usually works [09:28:34.0000] i'm planning to join it during breaks [09:28:36.0000] if you don't idle there people can't approach in a public fashion, would have to do it via DMs etc. which plenary couldn't pick up on [09:29:00.0000] bradley and i are in there already if people wanna join [09:30:13.0000] might need some contrast work https://usercontent.irccloud-cdn.com/file/MuiR0i0G/IMG_20200331_112945.jpg [09:38:31.0000] should the room be more.. fun? [09:39:17.0000] if you have to ask... ;) [09:39:27.0000] (just kidding, I'm still making breakfast over here) [09:39:58.0000] what does one do if one doesn't have a VR headset? :P [09:40:17.0000] drousso: you can just use WASD controls [09:40:23.0000] nice! [09:40:26.0000] is there a link? [09:40:35.0000] reflector [09:47:56.0000] there are some fun avatars in the Newest category hehe [09:49:29.0000] msaboff: [09:49:33.0000] oh oops [09:55:19.0000] over the next hour, folks are likely to request access details to dial in - in all cases please go to the Reflector link 275 (posted in the IRC channel subject) [10:06:16.0000] resolution 1x1 [10:06:37.0000] oh wow there are three pages of people [10:07:17.0000] it'd be great to keep chat to IRC, instead of zoom, during plenary stuff - it's hard enough to keep track of all the existing chat venues [10:07:47.0000] yes please [10:10:06.0000] bterlson: heads up if you want to call on somebody, as the zoom host, you can unmute them (which asks them to confirm) but it gets their attention [10:10:59.0000] there is also a stream of the zoom in the hub [10:11:15.0000] ystartsev: ah i didn't realize that, thanks [10:11:16.0000] suggestion: introduce yourself the first time you talk [10:11:31.0000] lol for Keith's background [10:11:36.0000] Bakkot: because that worked so well at JSConf EU :P [10:11:53.0000] (half kidding, I think it will work better in plenary) [10:12:04.0000] I wasn't there, so I will assume it worked perfectly [10:12:19.0000] you didn't watch our panel on YouTube? 😱 [10:12:25.0000] I'll link it in TDZ [10:13:45.0000] I don't watch videos as a rule [10:13:55.0000] that's...fair [10:17:10.0000] akirose: If you're doing the schedule, i have my constraints updated here https://github.com/tc39/agendas/blob/master/2020/03.md#schedule-constraints [10:17:18.0000] apologies for these being so last-minute [10:17:55.0000] ty for letting me know [10:20:29.0000] We have four note-takers who have generously volunteered for this session ahead of time: Rick, Philip, Mark, and Jason! [10:21:40.0000] πŸ‘ [10:21:48.0000] to clarify: invited experts only need to sign the IPR form *once ever*. No need to sign again for this meeting. [10:27:44.0000] akirose: are you using side-by-side mode? [10:27:58.0000] i have no idea what that is [10:28:10.0000] oh to see rob at the same time as the slides [10:28:22.0000] i have zoom full-screened and i'm flipping between it and the agenda schedule i'm working on [10:28:45.0000] devsnek: i see rob in the lower right corner, floating over the shared screen [10:28:50.0000] ooohh Oracle, that should be exciting [10:28:50.0000] aha full screen [10:30:13.0000] would love to have graal people participating more [10:38:02.0000] i wonder how the trademark thing will go if they do join [10:38:54.0000] bradleymeck: see tdz [10:48:37.0000] bterlson the Test262 update is not on the TCQ agenda [10:48:50.0000] whoops I'll add it [10:48:50.0000] leo? [10:48:58.0000] doing it? or you for old times sake? :-P [10:49:08.0000] Me [10:55:57.0000] I wanted to blurt out "workin' on it" re JSC but didn't know whether that was a New Topic or what lol [11:15:25.0000] akirose: MylesBorins: bterlson: for the schedule, not sure if the agenda view on tcq is up-to-date, but please schedule the incubator call chartering to be sometime on the last day [11:15:39.0000] (as noted in the schedule constraints) [11:15:57.0000] I don't think it is up to date [11:15:59.0000] it's not done yet, but i'll post the WIP schedule on the reflector [11:16:03.0000] ah okay, great [11:17:21.0000] nice speediness there jridgewell :D [11:17:42.0000] The tests aren't great… [11:18:03.0000] yeah but officially nonzero [11:18:22.0000] drousso might help me make more tests. [11:18:41.0000] πŸ‘ [11:22:29.0000] test [11:22:57.0000] hello jackworks79 [11:23:16.0000] does here a public IRC channel now? [11:24:14.0000] jackworks79: the public can view this IRC channel and read its logs, yes [11:25:16.0000] jackworks79: Only delegates can message, though [11:25:21.0000] #tc39 is the one which anyone can message [11:25:38.0000] (which I'd encourage using most of the time, but not for discussing ongoing meeting stuff) [11:29:29.0000] i need to apologizeβ€” Bakkot i'm asking you to go after lunch due to a scheduling constraint, maybe i'll ask s-h-u to do his PSA next instead. [11:29:51.0000] yup seems fine [11:29:59.0000] ty [11:32:51.0000] since when have we tried to prevent people from deadlocking themselves? [11:33:52.0000] the deadlock is that it will never wake up [11:33:56.0000] nothing can wake it [11:35:43.0000] while(1); [11:36:05.0000] michaelficarra since we started trying to design a memory model usable by mortals [11:36:32.0000] it is way less obvious when you've accidentally gotten into a deadlock with multithreading than when you just have an infinite loop, as a rule [11:36:48.0000] this was the single-threaded case though [11:37:18.0000] i think the design here is that you don't know if the buffer you're given is shared or not [11:37:26.0000] or more that you don't want to bother checking [11:38:03.0000] one of my friend is doing this thing to block the main JS thread: [11:38:23.0000] devsnek: good point [11:38:45.0000] jridgewell: with those logical assignment tests v [11:38:45.0000] https://gc.gy/53384906.png [11:38:56.0000] 100% coverage of the runtime semantics! [11:38:59.0000] with ({}) while (Atomics.load(...) === old) // blocking on the main thread [11:39:42.0000] πŸ˜‰ [11:41:15.0000] he said "if you won't allowing me to lock (Atomics.wait) on the main thread, I'll use a more hacky and stupid (while loop to check spin lock) to lock the main thread" [11:41:38.0000] someone's audio is dying [11:42:11.0000] I muted brian [11:42:21.0000] ty [11:42:22.0000] somehow I wound up with host privs so I used them :P [11:42:36.0000] drunk with power [11:44:20.0000] jackworks79: correct, but thats a spin lock instead of a full on sleep [11:46:24.0000] 0 is the new NaN, folks [11:46:45.0000] (he is making a remote sync DOM so he need to force block on the main thread to wait for the result from a remote DOM env) [11:47:17.0000] Symbol.for('es.no.waiters') [11:47:59.0000] what an excellent way to burn users' battery [11:48:20.0000] should use an evented model [11:49:38.0000] It's really difficult to provide an sync API over an async thread [11:49:51.0000] So, making it evented would just break the user's code [11:50:07.0000] AMP has the same issue with WorkerDOM [11:50:26.0000] yeah, in workers can use Atomics.wait to block the thread and make it fake sync [11:50:35.0000] make amp v2 [11:51:24.0000] can y'all give more of a heads-up when you move agenda items around? previously it was communicated that named groups would happen before lunch [11:51:51.0000] I love that the "frozen" slide is constantly moving [11:52:05.0000] We also are looking at this wait behavior for instrumenting CJS in Node [11:52:31.0000] but we don't have [[CanWait]] set to false for anything [11:52:32.0000] brad4d: it's snowflakes though [11:53:30.0000] RIP v8 8.2 [13:17:03.0000] πŸ‘€ https://gc.gy/53390815.png [13:17:26.0000] https://gc.gy/53390839.png [13:22:01.0000] agree with mathiasbynens πŸ‘ [13:24:09.0000] the whole `var y = { \u0066or: x } = { for: 42 };` is legal thing makes me cry too [13:24:25.0000] \u0066 in chat [13:25:00.0000] Bakkot: you didn't mention that in non-u regexps, there's a more interesting case for /\u{FOO}/ if FOO consists of 0-9 only e.g. `123456`: then, it matches the literal character `u` repeated `123456` times. [13:25:14.0000] (JSC has a ton of outstanding test262 failures about keywords-with-escapes as identifiers) [13:25:15.0000] (#funfact but didn't want to waste committee time) [13:25:35.0000] non-unicode regex has a lot of scary stuff [13:25:59.0000] I'd like to go on record as being opposed to allowing non-IdentifierNames in named groups, as they conflict with some RegExp related proposals I'm putting together. [13:26:44.0000] gibson042: can't the programs be expressed with \u{} [13:26:58.0000] I'm not convinced that Waldemar's asciifier should be a goal... it's possible to write, but would just be slightly more complicated [13:27:05.0000] (since it sounds like my question won't make it before the queue is cut off) [13:27:18.0000] so I don't understand why the goal needs to include that the asciifier is so simple [13:28:01.0000] I maintain such an asciifier... [13:28:10.0000] what is an asciifier [13:28:16.0000] if you quit and re-join you have you re-add your full name πŸ€¦πŸ»β€β™€οΈ [13:28:31.0000] turning things outside ascii range into escapes? [13:28:43.0000] akirose: yeah I can't figure out how to correct this :-/ [13:29:02.0000] mathiasbynens: waldemar's contention is that you can't convert a non-unicode regex into a unicode regex in general [13:29:10.0000] mathiasbynens: i don't know enough about regexps to say, is that actually true? [13:29:51.0000] i had to find my own face in the gallery and choose "rename" from the context menu [13:29:56.0000] I 口 Unicode [13:30:16.0000] gibson042: can you give an example? [13:31:34.0000] aah this is what i was missing earlier. we could totally make \u{...} work specifically for group names. i missed that gibson042 wouldn't want that [13:32:19.0000] The reason `\u{1d49c}` isn't supported without the `u` flag is for back compat, however there's no back-compat concern to allow them without the `u` flag in a named capture group, as named capture groups were new syntax so there is no back-compat hazard. [13:32:22.0000] please really consider if you must be on the queue - we have to end this topic in 6 mins [13:32:31.0000] rbuckton: exactly [13:32:43.0000] I don't think this is getting resolved in the next 10 minutes [13:33:15.0000] The main reason *not* to allow them would be confusion due to inconsistency. [13:33:32.0000] jackworks: your pseduo-tofu bothers me so much more than real tofu [13:33:38.0000] there's gonna be inconsistency in any case. we have to pick which inconsistency we want to live with [13:33:43.0000] are humans going to be confused by this though [13:33:47.0000] this is all tooling output [13:33:55.0000] i think the inconsistency between pattern + match.groups.IDENTIFIER is what matters most [13:34:13.0000] michaelficarra: lol I thought this too πŸ˜‚ [13:34:21.0000] +1 to mathias [13:36:16.0000] Then we could just allow any key name? [13:37:49.0000] use ['for'] syntax any key name is already allowed imo 🀣 [13:38:32.0000] 2 minute warning [13:41:30.0000] gibson042: isn't that what you objected to? [13:41:54.0000] what is the "this" here? [13:42:12.0000] I get the urgency to resolve this matter but it feels really rushed given the temp of the room [13:42:27.0000] I think \u{…} should have identical treatment in a non-Unicode regex regardless of its use for matching vs. capture-group naming [13:42:32.0000] akirose I would like to participate in "Make SharedArrayBuffer optional", but I also have to go at 5pm (hard stop, child care) [13:42:51.0000] We could come back to it with a longer time box, but it seems to be blocking to adopting ES 2020 [13:42:53.0000] i.e., equivalence with "u{…}" [13:42:54.0000] If shu doesn't mind, could we do that tomorrow? [13:43:06.0000] i'm flexible for my items [13:43:15.0000] shu I appreciate that [13:43:43.0000] gibson042: right, what kevin and waldemar were suggesting is, that `\u{1234}` would mean *that character* in both u and non-u regexes, not a literal "u{1234}", if i understand correctly [13:44:05.0000] gibson042: and i thought your position was, that in a non-u regex, `\u{1234}` must mean `u{1234}` [13:44:09.0000] i don't think we're talking about \u{nnn} at all...? [13:44:10.0000] akirose shu the only other item that I want to participate in is "Atomics.waitAsync error rejection PR", but presumably that wont be reached until tomorrow or Thursday anyway [13:44:14.0000] ah, I think you have misunderstood Waldemar at least [13:44:16.0000] ah k [13:44:22.0000] i'm asking about the current slide [13:44:25.0000] aren't we talking about the surrogate pair syntax only? [13:44:40.0000] rwaldron: yeah, if at all, it's a late addition so i expect it to be at the end of the meeting [13:44:45.0000] shu: the question's the same tho [13:44:46.0000] In all of this, there is the other part of capture group names, the first "character" needs to have the Identifier_Start property and subsequent "characters" have the propert Identifier_Continue. [13:44:51.0000] ljharb: it is? [13:44:53.0000] in a non-u regex, `\u` means `u` [13:44:57.0000] shu that's my expectation as well [13:45:04.0000] there's still a bunch of people who didn't fix their display name [13:45:06.0000] my understanding of gibson042's position was that that should remain true in named capture groups [13:45:11.0000] shu: ^ [13:45:51.0000] and my understanding of waldemar and kevin's preference was to make it be an actual character escape in non-u regexes (as well, ofc, as in u regexes) [13:45:59.0000] did i misunderstand? [13:47:18.0000] in order to represent in ASCII a regular expression with a non-BMP capture group name, it is necessary to allow *at least one of* `/(?<\ud835\udc9c>.)/` with surrogate-pair semantics or `/(?<\u{1d49c}>.)/` with code point semantics. I am against the latter because of inconsistency with \u{1d49c} in non-Unicode regexes outside of capture groups. [13:47:32.0000] and I believe that is also Waldemar's position [13:47:39.0000] ahhh ok [13:47:55.0000] so you want the non-curly surrogate pair syntax to mean "the char" but you want the curly form to be illegal (in a non-u regex)? [13:47:55.0000] I'm less sure about Kevin, but I think that matches as well [13:47:59.0000] why is ?<...> not always the ID_Identifier semantics [13:48:07.0000] er [13:48:11.0000] ID_... semantics [13:48:14.0000] gibson042: did my paraphrase make sense? [13:48:46.0000] i think i agree with shane that the thing in the arrows should always be an identifier [13:49:58.0000] akirose: well put [13:50:27.0000] I'm with Shane on this one I think it should just be an identifier prooduction [13:50:40.0000] IIUC [13:50:50.0000] that would allow \u{} [13:50:55.0000] correct [13:51:11.0000] πŸ‘πŸ» [13:51:12.0000] keith_miller: even in a non-unicode regex? [13:51:17.0000] yes [13:51:20.0000] I still don't understand Waldemar's ASCIIfier [13:51:24.0000] It's not observable there? [13:51:25.0000] My internet connection just died, I will try to rejoin shortly. [13:51:30.0000] You must be aware of the RegExp context [13:51:30.0000] I think that identifier production should be the same for both non-Unicode and Unicode RegExp's. [13:51:42.0000] because it's not actually used in part of the regexp [13:51:47.0000] ljharb:^ [13:51:53.0000] Because if you naively changed the pretty a until a `\u{CODE}` in a non-unicode regex, it'd break the regex. [13:52:00.0000] It's essentially a comment? [13:52:19.0000] keith_miller: ah ok, so the context is different for you between "the regex pattern itself" and "the annotation of the capture group" [13:52:28.0000] gibson042: thoughts on ^ ? [13:52:34.0000] And if we allow any "name" there, why not allow _any_ name? [13:52:35.0000] i think shane put it nicely with the template example [13:52:38.0000] jridgewell you can just change it to the pretty A into the two surrogate halves and it will work in both cases [13:52:44.0000] ${...} is like (<...> [13:52:44.0000] ljharb: yeah [13:52:51.0000] er (?<...> [13:53:20.0000] jridgewell the main reason not to allow any name is because it can conflict with numeric (non-named) matches, which isn't currently terrible but gets weird with some potential other features [13:53:23.0000] Bringing up Waldemar's funny behavior `\u123\u456*` isn't the same as `\u{12345}*` [13:53:36.0000] ljharb I agree with keith_miller. Capture group names should be treated separately to the RegExp's pattern [13:53:38.0000] So naive ASCIIfier is always needs to parse the regex. [13:53:41.0000] shane, are you in IRC? I don't know your handle [13:53:45.0000] sffc: [13:53:46.0000] It's just not possible to do otherwise. [13:54:06.0000] jridgewell but `\u123\u456*` is the same as `A*` [13:54:13.0000] in both unicode and non-unicode regexes [13:54:18.0000] (I think...) [13:54:19.0000] I am against `/(?<\u{1d49c}>\u{1d49c})/` returning a group named "π’œ" with value "u{1d49c}", which is what the "apply code point semantics specifically when naming capture groups" implies [13:54:27.0000] Be we can use the unicode codepoint anymore [13:54:41.0000] gibson042: ok - the thing you're against seems to be what a number of people are settling on [13:54:45.0000] i am okay with the example gibson042 just sent [13:55:12.0000] hi. ok, so I understand the desire to represent regexes as strings, in which case the thing inside (?<...>) is interpreted as a string. In that situation, though, then (?<0>) should produce a capture group named with the string "0". [13:55:26.0000] gibson042 there's a mandatory `>` after the group name, so you can't have that particular case [13:55:32.0000] having different semantics for "\u{…}" sequences based on where they appear in the regex is just too much cognitive burden for too little gain IMO [13:55:38.0000] gibson042: Won't allowing the surrogate code point do exactly that? [13:55:39.0000] yeah +1 to consistency about "what an identifier is" from me [13:55:56.0000] Bakkot: it's there [13:56:04.0000] oh, sorry, I can't read [13:56:07.0000] yup [13:56:19.0000] Bakkot Your slides said that let \ud835\udc9c; is not valid, but let \u{1d49c}; is. Shouldn't RegExp capture names be the same? [13:56:44.0000] we're talking about IdentifierNames, right? not Identifier? [13:57:11.0000] separate question: has anyone ever suggested making `let \ud835\udc9c;` valid? [13:57:11.0000] michaelficarra: yes [13:57:12.0000] I *really* hope we wouldn't apply ReservedWord restrictions to named capture groups [13:57:12.0000] That is my understandng. [13:57:37.0000] rkirsling: I'm actually not sure why that's invalid [13:57:40.0000] I can't figure it out [13:58:18.0000] michaelficarra because `\ud835` is not ID_Start [13:58:18.0000] remember that `let \u0065` is valid, so why wouldn't surrogate halves be valid? [13:58:38.0000] oh really, it checks the first code unit for ID_Start? [13:58:40.0000] okay then [13:59:13.0000] alright that's fair [13:59:20.0000] btw where should we having the priority discussion? [13:59:46.0000] some people felt that it was unacceptable for the spec to go out with known incoherencies, but I think it's fine [14:00:28.0000] Bakkot If that is the case, don't we want named capture group name syntax to be the same as identifiers? [14:00:48.0000] I actually think that if we allow \u{}, we should also allow \u\u [14:01:08.0000] that would be iffy [14:01:18.0000] \u\u isn't disallowed btw [14:01:29.0000] its just that the first one isn't a valid identifier start [14:01:53.0000] Reading the notes, I think WH's point was that anything represented in `/.../` syntax should also be able to be represented in `new RegExp("...")` syntax [14:02:01.0000] and vice-verse [14:02:35.0000] akirose shu I have to go now, but I think this proposal is ok [14:02:43.0000] See you all tomorrow. [14:02:47.0000] πŸ‘‹πŸ» [14:02:50.0000] I haven't looked at the spec or our parser to see if a valid first surrogate \u is followed by a valid second surrogate that it is supposed to be treaded as a single Unicode code point. [14:02:51.0000] ty rwaldron [14:03:46.0000] msaboff: https://tc39.es/ecma262/#sec-identifier-names-static-semantics-early-errors [14:04:05.0000] Thanks, looking... [14:04:09.0000] the first rule [14:04:09.0000] it's stronger than that... anything representable in `/…/` should be representable without using any code unit outside of 0x20 through 0x7E [14:04:10.0000] It is a Syntax Error if the SV of UnicodeEscapeSequence is none of "$", or "_", or the UTF16Encoding of a code point matched by the UnicodeIDStart lexical grammar production. [14:04:15.0000] msaboff y'alls parser has a bunch of problems with non-BMP in general [14:04:20.0000] doesn't even allow `let π’œ` [14:04:41.0000] we'd have to modify our grammar to perform utf16 decoding on identifiers [14:04:58.0000] just typing that gives me shivers [14:06:27.0000] devsnek That says that \uHHHH is for BMP characters only. [14:07:10.0000] what does [14:08:29.0000] The spec only allows for one escape for an IdentifierStart or IndentifierPart. That is only one \uHHHH escape and not two together [14:08:40.0000] right [14:09:01.0000] If you want a non-BMP codepoint, you have to use \u{} [14:09:04.0000] right [14:09:47.0000] Given we aren't likely to change this for identifiers, I think named capture group identifiers should follow the same rules. [14:10:03.0000] Thins would include non-Unicode RegExps [14:10:20.0000] indeed [14:10:49.0000] I think we should change it for identifiers [14:11:12.0000] with the effect that `/(?<\u{1d49c}>\u{1d49c})/` returns a group named "π’œ" with value "u{1d49c}", as gibson042 pointed out above? [14:11:16.0000] msaboff ^ [14:11:24.0000] Can someone explain the argument for allowing \u\u in capturing groups? [14:11:41.0000] sffc: that code example that bakkot just posted [14:11:53.0000] devsnek sffc I will write it out; it is not that code example [14:12:00.0000] Bakkot Yes it would. [14:12:06.0000] it isn't? [14:12:16.0000] i thought the entire argument was that the example shouldn't be allowed [14:12:20.0000] so you'd have to use surrogate pairs [14:12:49.0000] devsnek oh I guess that's part of it [14:12:51.0000] let me write it out. [14:13:17.0000] shu: found the comment about different alloc trade offs https://freenode.logbot.info/tc39/20200219#c3271588-c3271590 that i was curious about, just a note no action [14:13:50.0000] I don't see what Bakkot's example has to do with `(?<\u\u>)`; the question of what to do with `(?<\u{}>)` is a separate question [14:14:09.0000] this makes me want to buy facerig now [14:14:27.0000] sffc the major argument is, currently if you are turning a JS source text into ascii you can do that for regexes by replacing any non-BMP with two escaped surrogate halves. if we disallow `\u\u`, now you have to actually parse it. and if you can't use `(?<\u{1d49c}>` in non-unicode regexs, then you can't do the thing you are trying to do at all; some people think you should not be able to use that (this is the relevance of my [14:14:27.0000] previous example). [14:15:18.0000] how are they just replacing everything with surrogate pairs [14:15:21.0000] those aren't valid identifiers [14:15:27.0000] "for regexes" [14:15:29.0000] bradleymeck: yeah, that's the buffer allocated if you go through Wasm.Memory [14:15:33.0000] ohhh just for regexes [14:15:40.0000] bradleymeck: once you get the SAB constructor back out, that follows JS rules (no rounding, page boundaries, wahtever) [14:17:23.0000] Bakkot: so the problem is only for non-unicode regexes. But we already don't allow Unicode identifiers as capture group names in non-unicode regexes, according to the last slide in the presentation. [14:17:47.0000] the current state is incoherent. [14:18:04.0000] we neither allow nor disallow; I apologize that my slides suggested otherwise. [14:19:10.0000] It makes sense if `/(?<\u{1d49c}>\u{1d49c})/` would have the behavior you suggested earlier (returns a group named "π’œ" with value "u{1d49c}"). Maybe it's a little weird, but it's well-defined. [14:19:11.0000] Bakkot Would you be fine with allowing \u{} in a named capture group ID for non-unicode RegExps? [14:20:00.0000] Alternatively, it would make sense if you just forbid all non-BMP identifiers in non-unicode RegExp capture group names, in which case your example would be a compile error. [14:20:59.0000] you can't do that; `/(?<π’œ>.)/` is already valid [14:21:22.0000] gibson042 this feature is not widely enough used for us to worry about back compat, I think [14:21:39.0000] ok, fair enough [14:21:50.0000] I think we can separate what is valid for a capture group identifier and what is match by the RegExp [14:21:58.0000] msaboff I would (actually my assumed it was uncontroversial that they should be allowed); other people have said they would object to that, though. [14:22:04.0000] *actually my presentation assumed [14:22:49.0000] reminder: please add your company name to your Zoom display name [14:22:53.0000] private fields aren't in the spec btw [14:23:19.0000] right, this is about adding it to the stage 3 private fields spec [14:23:35.0000] mhm [14:23:44.0000] Bakkot And then would you also support NOT allowing \uHHHH\uHHHH as a surrogate pair as a named capture group ID. It could be valid if each escape is a valid ID start / IS part. [14:24:24.0000] can't we just use IdentifierName [14:25:11.0000] people arguing for `/(?<\u{1d49c}>.)/` to be equivalent to `/(?<π’œ>.)/` while `/\u{1d49c}/` is NOT equivalent to `/π’œ/`... what's the benefit? [14:25:28.0000] `foo?.bar.#baz` => `foo == null ? undefined : foo.bar.#baz` [14:25:35.0000] msaboff I lean towards the other side of that question. I think approximately zero humans ever write or read code containing unicode escapes in named capture groups, so it makes sense to make things as easy as possible for tooling responsible for generating it. Allowing escaped surrogate halves here makes it easy for tooling. [14:26:24.0000] gibson042: that we use a consistent identifier everywhere [14:26:27.0000] gibson042: what would Waldemar's hypothetical ASCIIfier return for the regexp-stored-as-string '[-]', with the condition that it doesn't know whether the target RegExp will have the u flag or not? [14:26:45.0000] I get that, but does it make sense to have different grammar rules for identifiers in the language versus named capture group identifiers? [14:26:50.0000] gibson042: if you know you end up in a `u` regexp, you can output `/\0-\u{10FFFF}/u` and call it a day, but that pattern wouldn't work in non-`u` [14:26:58.0000] mathiasbynens you can replace those with the two surrogate halves and it will preserve semantics in both cases, I am almost certain. [14:27:25.0000] Bakkot: well no you'd break the range in the non-u case [14:27:29.0000] how sure are you? [14:27:35.0000] Bakkot: 100% [14:27:56.0000] Bakkot: since you're now creating a range between U+0000 and highSurrogate(U+10FFFF) [14:28:01.0000] Bakkot I don't think so. In mathiasbynens example, the RegExp is quite different with and without /u [14:28:18.0000] mathiasbynens "since you're now creating"... in the non-u case? [14:28:22.0000] and then trailSurrogate(U+10FFFF) is a lone character in the character class... [14:28:24.0000] are you sure that's not what you already had? [14:28:27.0000] I think that's what you already had [14:28:57.0000] Bakkot: it isn't, is what i'm saying [14:29:45.0000] gus's point here is really good. [14:30:03.0000] :D [14:30:48.0000] /me reverts PR to original state [14:30:58.0000] lol [14:30:58.0000] πŸ‘ [14:31:04.0000] mathiasbynens I am pretty sure that's what you already had, at least in real engines [14:31:57.0000] `/^[π’œ]$/.test('\ud835')` is "true" [14:32:08.0000] i think bmeck suggested we should set up specifying optional chaining and member expressions using some sort of macro syntax [14:32:15.0000] Bakkot: I'm not talking about engines? [14:32:19.0000] i'd be in favor of doing such a thing [14:32:20.0000] mathiasbynens I think also per spec, sorry [14:32:29.0000] I think the main question for me is how `...` in `(?<...>)` is interpreted. If it's an identifier, then `\u\u` should be disallowed. If it's a string, then `0` should be allowed. [14:32:35.0000] Bakkot: I'm talking about neither of those things :/ [14:32:44.0000] mathiasbynens sorry, I am confused then [14:32:59.0000] Bakkot If mathiasbynens range was written with the last codepoint in the range as two \u escapes, do you agree with what he says the range becomes? [14:33:09.0000] lol, "@jridgewell pushed 0 commits." [14:33:21.0000] msaboff yes, my point is that it was already that thing to start with, I'm pretty sure [14:33:46.0000] Bakkot: waldemar described an asciifier that takes a regexp-stored-as-string and turns it into an actual piece of sourcetext representing a regexp literal, WITHOUT knowing whether that literal will get a `u` flag or not [14:33:52.0000] With the /u flag it is completely different. [14:33:56.0000] mathiasbynens yes? [14:33:56.0000] the consensus to the optional chaining for hash names was allow everywhere, right? [14:34:05.0000] msaboff it only becomes that thing in non-unicode regexes [14:34:07.0000] (i'm confused by the second sentence in the consensus in the notes) [14:34:10.0000] shu: yes [14:34:12.0000] I think I pushed -2 commits. [14:34:13.0000] in unicode regexes, it is still the single range [14:34:28.0000] I think we agree [14:34:39.0000] let me write out the four cases here [14:34:54.0000] Bakkot: that's my point. the asciifier already needs to either a) know whether or not it gets the u flag or b) go out of its way to produce polyglot patterns that work properly in either case [14:35:12.0000] mathiasbynens can it not just unconditionally put the two surrogate halves? [14:35:18.0000] that is what I am having trouble with. [14:35:27.0000] if not, why not? [14:35:31.0000] what case does that break, and why does it break it? [14:35:41.0000] So is waldemar's point that both `/(?<π’œ>/` and `/(?<π’œ>/u` asciify to the same thing? [14:35:44.0000] I think that an asciifier must know if the u flag is present. [14:35:59.0000] (I'm missing a `)` in those examples) [14:36:17.0000] that would behave differently with u vs non-u [14:36:25.0000] yeah, are we really saying that there's currently ALWAYS a way to write a regexp-as-string without knowing whether it's unicode? [14:36:30.0000] mathiasbynens _what_ would behave differently with `u` vs non-`u`? [14:36:33.0000] like, why would that invariant ever exist? [14:36:37.0000] Bakkot: another example: `'[πŸ’©-πŸ’«]'` [14:36:52.0000] Bakkot: what would you output that works in both `u` and non-`u`? [14:37:02.0000] that's never a legal non-u regex, so you don't have to worry about it [14:37:29.0000] Bakkot: you're changing the goalposts though, the asciifier needs to produce output that's valid for either, since it doesn't know! [14:37:42.0000] https://mathiasbynens.be/notes/es6-unicode-regex is full of examples [14:38:02.0000] I think we are heading into the weeds here. Lets focus on the named capture group IDs. [14:38:09.0000] yes, please [14:38:17.0000] mathiasbynens outputting '[\uXXX\uXXX-\uXXX\uXXX]' will preserve the semantics: in the non-u case it is (still) an error, and in the u case it is (still) a single range [14:38:28.0000] so your asciifier has preserved the semantics [14:38:31.0000] which is what it needed to do [14:38:40.0000] (sorry, four Xs, obviously) [14:39:14.0000] When you're not in a named capture group, your asciifyer can output `\u\u`. I think that's fine. [14:39:29.0000] littledan: github has a "template" feature; you don't need to fork it, you *should* click the "use this template" button [14:39:31.0000] Thee is the interesting case of a RegExp with a NCG ID with non-BMP characters, but I don't think that is too controversial [14:39:42.0000] the whole asciifier argument doesn't make sense. it's possible to produce patterns that work in either case, but it needs some work. capture group IDs would not be unique [14:39:46.0000] littledan: as opposed to making a totally disconnected repo [14:39:57.0000] mathiasbynens... what? [14:40:01.0000] ljharb: Oh cool. Could we point people to this? [14:40:09.0000] littledan: it's a big green button on the template repo [14:40:22.0000] repeating myself: in order to represent in ASCII a regular expression with a non-BMP capture group name, it is necessary to allow *at least one of* `/(?<\ud835\udc9c>.)/` with surrogate-pair semantics or `/(?<\u{1d49c}>.)/` with code point semantics. I am against the latter because of inconsistency with \u{1d49c} in non-Unicode regexes outside of capture groups. [14:40:36.0000] littledan: https://github.com/tc39/template-for-proposals [14:40:41.0000] heh yeah that's really clear [14:40:44.0000] sorry [14:40:54.0000] mathiasbynens I am confused. my point is, currently you can write a regex asciifier which preserves semantics easily. if you have to parse it and treat named capture groups and non-named-capture groups, it is now harder. do you disagree with either of those two sentences? if so, which and why? [14:41:03.0000] littledan: np, the feature didn't exist when i first made the template [14:41:21.0000] hmm, should we tell people to use that button in the #create-your-proposal-repo section? [14:41:34.0000] ideally, but i wasn't sure the committee had consensus on recommending that template yet [14:41:44.0000] gibson042 other people are in favor of allowing `/(?<\u{1d49c}>.)/`, it sounds like, and damn the inconsistency (which seems fair enough to me; no human will ever write that code so the inconsistency isn't really a problem) [14:41:46.0000] gibson042: I don't care about the inconsistency you mention. I find it more inconsistent that we are introducing a context in which we allow surrogate pairs as identifier names. [14:42:18.0000] Bakkot: "easily"? you got the `-` wrong [14:42:19.0000] gibson042 The problem is that \ud835\udc9c is not valid for a JS identifier but \u{1d49c} is. [14:42:30.0000] So I'm +1 to "damn the inconsistency" [14:42:31.0000] mathiasbynens I still do not understand how I got it wrong. [14:42:49.0000] Bakkot: what would you output? [14:42:49.0000] mathiasbynens please give an example of a regex where the output of my algorithm does not have the same semantics as the input. [14:42:59.0000] So you want different syntax for specifying an ID inthe two contexts [14:43:14.0000] mathiasbynens '[\uXXXX\uXXXX-\uXXXX\uXXXX]' [14:43:30.0000] Bakkot: what would \uXXXX\uXXXX look like for U+0000 exactly? [14:43:44.0000] mathiasbynens sorry, yes, for BMP code points it would just be `\uXXXX`, of course [14:43:53.0000] so, `\u0000` [14:44:20.0000] that's not a working regexp :/ [14:44:24.0000] "where the output of my algorithm does not have the same semantics as the input" is key [14:44:35.0000] mathiasbynens _neither was the input_ [14:44:43.0000] so the semantics are preserved [14:44:45.0000] Waldemar is saying his asciifier doesn't know which output flags are used [14:44:55.0000] or, wait, hang on [14:45:01.0000] wait why isn't it a working regex [14:45:09.0000] the input _is_ valid [14:45:13.0000] I keep getting confused between this and the '[πŸ’©-πŸ’«]' case [14:45:23.0000] mathiasbynens why isn't it a working regex [14:45:28.0000] Do we have agreement on allowing `/(?<\u{1d49c}>\u{1d49c})/` with the inconsistency about `\u{1d49c}` being interpreted differently in the capture group versus the main regex? [14:45:37.0000] back in 10 mins! [14:45:42.0000] sffc gibson042 explicitly objected to that [14:46:03.0000] as did Waldemar, and probably more strongly than me if we're being honest [14:46:26.0000] sffc I'm fine with that [14:46:27.0000] that's a pretty strong point of contention among the committee then :( [14:46:31.0000] Bakkot: so you'd do something like [\0-\uLEAD\uTRAIL], which creates a range between U+0000 and U+LEAD, and then adds U+TRAIL as a lone character [14:46:39.0000] mathiasbynens right, which is what your input regex did. [14:47:07.0000] Bakkot: no, the input is a string, which represents a regex, per Waldemar's description [14:47:12.0000] The alternative from my perspective is if we allow `/(?<0>.)/` and interpret "0" as a string, such that you can do `.groups["0"]` [14:47:19.0000] or rather: right, that's what it does in the non-u case, which is what the input regex did in the non-u case. in the u case it creates a single range, which is what the input regex did in the u case. [14:47:30.0000] Bakkot: you cannot say that's what the input did, because you cannot know this without knowing whether it's `u` vs non-`u` [14:47:42.0000] which this supposed asciifier doesn't [14:48:03.0000] so you cannot produce a broken pattern, you have to make something that works [14:48:27.0000] mathiasbynens the job of the asciifier is to preserve the semantics. that is it's only job. if the input was going to be used with `u`, the semantics are preserved. if the input was going to be used without `u`, the semantics are preserved. so the semantics are preserved either way. [14:49:15.0000] do you disagree about the job of the asciifier, or do you disagree that in both branches the semantics are the same? [14:49:26.0000] What would an asciifier do with [14:49:26.0000] let s = "[\0-]"; [14:49:27.0000] r = new RegExp(s, "u") [14:49:38.0000] ^ [14:49:52.0000] Where the is the actual character [14:49:57.0000] msaboff `let s = [\u0000-\uTRAIL\uLEAD]"` [14:50:12.0000] r then has the same semantics [14:50:23.0000] it does not lol [14:50:38.0000] Can someone address my question about whether the capture group is a string, an identifier, or something special? My understanding is that if we go with what gibson042 and waldemar prefer, then we're introducing a new context where surrogate pairs are allowed as identifiers, but other strings are not. [14:51:36.0000] sffc: it (should be) an identifier [14:51:38.0000] Bakkot: oh you meant a leading quote there [14:51:41.0000] mathiasbynens: Bakkot's point is that for both Unicode and non-Unicode regular expressions, `[\0-\ud835\udc9c]` is equivalent to `[\0-π’œ]` so that contextual awareness is irrelevant [14:52:22.0000] mathiasbynens yes, leading quote, of course [14:52:35.0000] yeah what gibson042 said [14:52:52.0000] ok the disconnect is, i've been thinking of an asciifier that's like a JS function that accepts a string [14:53:06.0000] whereas you see it as a tool operating on the source code [14:53:15.0000] gibson042: if the capture group name is an identifier, then how do you justify the inconsistency of allowing `\u\u` in this context but not in a `let \u\u` context? [14:54:03.0000] I'd prefer it in both, but would justify the inconsistency by pointing out that this is an encoding inside a literal [14:54:09.0000] if that's what you're doing, you could just transform any such group names globally, right? [14:54:18.0000] much like variable name minification [14:54:49.0000] but not without changing potentially observable semantics, sure [14:55:13.0000] and the prohibition against non-IdentifierNames could in principle be relaxed without changing my position [14:55:33.0000] gibson042: ok, so we agree that we have an inconsistency with both outcomes. [14:55:34.0000] to be fair even the asciifier would have observable semantics :P [14:55:48.0000] keith_miller: right... [14:55:48.0000] The rule in https://tc39.es/ecma262/#prod-RegExpIdentifierName resolves to RegExpIdentifierStart folowed by RegExpIdentifierPart, but they have the same productions as IdentifierStart and IdentifierPart [14:55:49.0000] `/[\0-\ud835\udc9c]/u` is not equivalent to `/[\0-π’œ]/u` [14:55:51.0000] changes [14:56:03.0000] because you changed the length of the file [14:56:12.0000] and .source and .toString() etc. [14:56:17.0000] jridgewell how sure of that claim are you [14:56:18.0000] sffc: it's an inconsistency of the same sort that allows `\n` but not raw U+000A in string literals [14:56:29.0000] I just tested in Chrome [14:56:50.0000] jridgewell what test did you run? [14:56:51.0000] jridgewell: for what input do you get different results? [14:56:54.0000] keith_miller: that's not really observable in JS tho [14:56:59.0000] Nope, never mind, I forgot to change it. [14:57:11.0000] I hit up twice. 😳 [14:57:21.0000] I meant function length [14:57:25.0000] ljharb:^ [14:57:28.0000] sorry [14:58:00.0000] gibson042 What is the behavior of `/(?<\ud835\udc9c>.)/` in your preference? Does it throw? [14:58:05.0000] ljharb: function tostring, and source + toString on the regexp too [14:58:52.0000] sffc: no, it is equivalent to `/(?<π’œ>.)/` [14:58:56.0000] keith_miller: ah true [14:59:02.0000] mathiasbynens: also true [14:59:22.0000] it is how you express non-BMP capture group names without using non-ASCII source [14:59:52.0000] gibson042: right, so you consider `/(?<π’œ>.)/` a valid regex that produces a group name of "π’œ"? [14:59:58.0000] mathiasbynens what did you mean by "transform any such group names globally"? [14:59:59.0000] just like `/(\ud835\udc9c/` is how you express non-BMP matches without using non-ASCII source [15:00:06.0000] yes [15:00:29.0000] err, just like `/\ud835\udc9c/` is how you express non-BMP matches without using non-ASCII source [15:01:17.0000] Bakkot: what do you think about allowing non-IdentifierNames in the regex capture group name, as gibson042 suggested would be compatible with his position? [15:01:18.0000] Bakkot: like if the tool sees a group named `π’œ` it could rename that to `__renamed_1` and give `match.groups.π’œ` the same treatment [15:01:58.0000] mathiasbynens sure, but `x = match.groups; x.π’œ` is harder [15:02:05.0000] Bakkot: yeah [15:02:06.0000] and by "harder" I mean "uncomputable" [15:02:39.0000] I think we are letting this asciifier argument have too much sway. Do we think this is a major use case? [15:02:50.0000] sffc I would not want to allow capture group names which, when considered as code points, are not identifiers [15:03:10.0000] msaboff in honesty I think it's pretty much the only use case. [15:03:28.0000] msaboff that is, I don't think a human is ever going to write unicode escape sequences in group names. it's always going to be tools. [15:03:43.0000] so, my preference is to make life easy for tools. [15:04:04.0000] so just allow \u{} everywhere [15:04:18.0000] if that's your only goal [15:04:35.0000] michaelficarra: we can't do that in non-u regexps OUTSIDE of named groups, but within named groups yesssssssssssssss I'm all for it [15:04:40.0000] I don't know how prevalent of a use case it is, but I believe that humans WILL write unicode escapes for group names. Not common but likely given the use of poor dev tools. [15:05:35.0000] msaboff it's pretty common; I have seen multiple bespoke JS-asciification tools in use at enterprises (all broken to some extent, but we don't need to make them more broken) [15:05:35.0000] michaelficarra I'm for it in NCG IDs as well. [15:05:56.0000] michaelficarra as mathiasbynens says, you can't do it outside of group names. so now the tools have to parse the regex, instead of blindingly replacing everything in the regex. [15:05:57.0000] is there not just a babel plugin [15:06:13.0000] Bakkot: can you explain why you would not want to allow non-identifiers in capture group names? [15:06:17.0000] so sffc and maybe mathiasbynens are against allowing `/(?<\ud835\udc9c>.)/` because of IdentifierName, and Waldmar and I are against allowing `/(?<\u{1d49c}>.)/` because of non-/u regexp semantics [15:06:22.0000] actually doesn't babel shell out to a regex parser [15:06:32.0000] but at least one of them must be allowed in order to support all-ASCII source [15:06:51.0000] gibson042: that's my understanding of the situation, yes [15:06:53.0000] I just want (or would like) to be able to copy-paste π’œπ’œπ’œ in `/(?<π’œπ’œπ’œ>.)/` and the corresponding `match.groups.π’œπ’œπ’œ` [15:06:57.0000] in all cases [15:07:03.0000] Bakkot What would an asciifier do for the "let \u{1d49c};" case? [15:07:23.0000] that's already ASCII, so it would leave it alone [15:08:19.0000] sffc: two reasons: one is that having `>` gets weird, and the other is that having numerics like `0` gets weird [15:08:20.0000] Okay, then what does an asciifier do for "let π’œ;"? Won't it also convert it to "let \u{1d49c};"? [15:08:50.0000] If so, it can't do that without context. [15:08:54.0000] Bakkot mathiasbynens: sorry yes that's what I meant by "everwhere"; "regardless of u flag, inside NCGs" [15:08:58.0000] yes, it would have to [15:09:28.0000] So the only weird context is in the pattern part of a RegExp? [15:09:29.0000] unless we allow surrogate pairs wherever \u{…} is allowed, an asciifier must parse [15:09:43.0000] must tokenize [15:09:46.0000] doesn't have to do a full parse [15:09:57.0000] gibson042 I think that is a breaking change for nomral identifiers. [15:09:58.0000] (except as necesary for tokenization) [15:10:15.0000] is there any possible (?< in regex that isn't a group name [15:10:21.0000] Bakkot: +1 [15:10:23.0000] devsnek: `\(?<` [15:10:35.0000] ok excluding escapes [15:10:55.0000] '[(?<]' [15:10:58.0000] I don't think so besides the escape. [15:11:05.0000] Bakkot: wouldn't that require a parse [15:11:07.0000] not just tokenize [15:11:19.0000] to know you're inside a capture group [15:11:24.0000] er [15:11:57.0000] character set [15:12:00.0000] whatever you call brackets [15:12:03.0000] character class [15:12:11.0000] hmm interesting [15:13:39.0000] devsnek why? [15:13:51.0000] What should an asciifier do with: [15:13:51.0000] let first = "\0"; [15:13:53.0000] let last = "π’œ"; [15:14:01.0000] cuz you have to know whether you're parsing a group name or not [15:14:13.0000] theoretically [15:14:30.0000] let r = new RegExp("[" + first + "-" + last + "]") [15:14:32.0000] devsnek: my desired state is, we end up such that you can replace any non-bmp in any regex (or string) with two escaped surrogates [15:14:53.0000] msaboff you can also safely replace non-BMP code points in strings with two escaped surrogate halves [15:15:05.0000] i mean if we went with "whatever identifiers do" [15:15:17.0000] devsnek oh, yes. that's my point; that's what I am hoping to avoid. [15:15:23.0000] it's also worth noting that `let \u0061\u0061` *is* valid, but `let \ud835\udc9c` is not simply because code unit U+D835 is not treated as part of a surrogate pair [15:15:50.0000] Bakkot: I agree [15:16:15.0000] That doesn't work for let r = new RegExp("(?<" + last + ">.)"); [15:16:37.0000] msaboff how does it not? [15:17:03.0000] If the asciifyer isn't able to have different behavior based on whether you are in a capture group or whether you are in a Unicode vs non-Unicode regex, then you need to expand to `\u\u`. Are those two restrictions required for the asciifyer? [15:17:07.0000] let last = '\uD835\uDC9C'; // which is === 'π’œ' [15:17:17.0000] I doubt that the two surrogate escapes are ID_Start and ID_Continue [15:17:28.0000] exactly [15:17:53.0000] there won't be any escapes by the time you put it into the RegExp at runtime [15:19:00.0000] sffc in practice, most asciifiers I see in the wild are bespoke and at least a little bit broken because they are not aware of all the absurd edge cases in JS. I am hopeful we can minimize new sharp edges. [15:19:29.0000] if `let \ud835\udc9c` were interpreted analogously to `"\ud835\udc9c"`, with the two escapes recognized as a single code point, then an asciifier could always replace non-ASCII code points with \u…\u… surrogate pairs [15:19:45.0000] gibson042: non-Unicode regexes already have strange behavior when you embed Unicode characters. We're making the behavior no less strange. [15:20:01.0000] in general, it seems bad to expose the concept of surrogates in more places [15:20:13.0000] we're not talking about changing the semantics of non-Unicode regexes with non-ASCII characters [15:20:22.0000] +1 mathiasbynens [15:20:45.0000] I actually disagree with that, but it's a bit of a tangent anyway [15:20:53.0000] sffc we are making the behavior harder for tools to get right, and no harder for humans to get right [15:21:47.0000] gibson042: asciifyers aside, what should `/(?<\u{1d49c}>.)/` do in your opinion? [15:23:12.0000] it should be recognized as equivalent to `/(?.)/`, i.e. an attempt to create a regex with a capture group named "u{1d49c}" [15:23:26.0000] oof [15:23:29.0000] I do not like that option [15:23:36.0000] which is currently invalid because group names must be IdentifierNames [15:24:08.0000] just like `/\u{1d49c}/` matches only "u{1d49c}" [15:24:44.0000] named captures should have been `u`-only [15:24:45.0000] IOW, "\u{" has no special semantics in non-Unicode regular expressions [15:25:00.0000] so the effective answer is, it should be an error, right? [15:25:07.0000] yes [15:25:33.0000] ok good that's not so bad then [15:26:06.0000] mathias +1 [15:26:26.0000] and the spec machinery would be essentially "UTF16Decode, then require the result to conform with IdentifierName" [15:27:39.0000] i'd rather push proper unicode escapes into old regex than push old escapes into identifiers [15:27:55.0000] but you *can't* push them all the way in [15:28:01.0000] devsnek: would be amazing if that was web compatible :o [15:28:08.0000] devsnek: they already exist in identifiers, they're just arguably handled wrong [15:28:19.0000] i meant in the group name [15:28:21.0000] not generally [15:28:26.0000] oh :-( [15:28:29.0000] lol [15:28:39.0000] devsnek: ah yes, 100% agree [15:28:42.0000] tfw you confuse three people all at once [15:28:50.0000] in different ways [15:29:02.0000] shu: Out of curiosity how did this API come up? [15:29:10.0000] Was it from talking to graphics peoples? [15:30:03.0000] gibson042: sorry for being a broken record, but why is that inconsistency (of \u{...} being allowed in named groups, but not elsewhere, in non-u regexps) too much for you? [15:30:50.0000] ^ and is this an objection and not just a dispreference? [15:31:24.0000] gibson042: i don't understand how that apparently outweighs the `/(?<π’œπ’œπ’œ>.)/u` && `match.groups.π’œπ’œπ’œ` consistency, which seems much more common [15:31:48.0000] mathiasbynens: wait, what inconsistency [15:32:01.0000] has anyone suggested `/(?<π’œπ’œπ’œ>.)/u` && `match.groups.π’œπ’œπ’œ` not work? [15:32:11.0000] no [15:32:46.0000] in plenary when it was suggested that we could make \u{...} work in group names within non-u RegExps [15:32:55.0000] ah [15:33:03.0000] (I am fine with that fwiw) [15:33:10.0000] mathiasbynens: also, same question for you: why is the inconsistency of `\u\u` being allowed in named group names, but not in identifiers outside of literals, too much for you? [15:33:13.0000] gibson042 said that'd be inconsistent with \u{} elsewhere in non-u RegExps (which is true) [15:34:04.0000] Bakkot: the way i see it, we have to choose between the two, and so we should choose based on which pattern is more common [15:34:12.0000] It's too much because it adds *even more* complexity to an already overwhelming part of the language, and does so for very little benefit IMO. This is a strong dispreference, but I (though not necessarily Waldemar) would yield to supermajority. [15:34:40.0000] mathiasbynens: why do you see it that we have to choose between the two? [15:35:09.0000] mathiasbynens: my preference is to allow both (in both kind of regexes), as we do in strings and `u` regexs [15:35:34.0000] sffc and maybe mathiasbynens are against allowing `/(?<\ud835\udc9c>.)/` because of IdentifierName, and Waldmar and I are against allowing `/(?<\u{1d49c}>.)/` because of non-Unicode regexp semantics... but at least one of them must be allowed in order to support all-ASCII source [15:35:45.0000] this makes life easiest for tooling authors and creates in expectation zero problems for any other humans, I would guess [15:36:09.0000] what gibson said ^ [15:36:11.0000] ugh [15:36:17.0000] did i get that wrong? [15:36:22.0000] yeah I think that's correct [15:36:38.0000] I would like us to think first about what the actual effects of our decisions on future humans will be [15:36:42.0000] and i agree on "zero problems for humans" [15:36:59.0000] i just don't like to make the language uglier by allowing surrogates in more places [15:37:43.0000] I appreciate that preference, I just think it should be outweighed by the relatively substantial likelihood that this decision leads to someone shipping broken code to real users as a result of tooling which is not aware of this edge case [15:37:44.0000] i would hope (perhaps naively) that future humans always use the `u` flag [15:37:57.0000] some will, many won't [15:37:59.0000] isn't it worse to have `\ud835\udc9c` sometimes be two code points and sometimes one? [15:39:36.0000] keith_miller: oh, no, not from the graphics folks [15:39:50.0000] gibson042: hmm? [15:39:59.0000] Interesting, where did it come up? [15:40:53.0000] regarding "i just don't like to make the language uglier by allowing surrogates in more places", I think it's worse to have more places where `\ud835\udc9c` represents two code points rather than one [15:41:20.0000] benjamn: wait, import.meta inherits from Module.prototype in node?? [15:41:26.0000] benjamn: or, you might want it to [15:41:28.0000] keith_miller: surma brought it up in working with bitmaps pulling out the A's instead of the RGB's, i think is the direct motivating example [15:41:40.0000] got it [15:41:40.0000] ljharb: no, but Module.prototype was a useful feature of CommonJS [15:41:53.0000] gibson042: if it's forbidden it doesn't really represent anything [15:41:56.0000] keith_miller: and indeed, the plan for RGBs was to make 3 views for each channel [15:42:53.0000] because `/(?<\u0061\u0061>.)/` is valid now and will presumably remain valid [15:42:55.0000] gibson042: i don't follow. how does allowing \{...} in non-u RegExp group names increase the number of cases where `\ud835\udc9c` represents 2 code points? [15:42:59.0000] keith_miller: there's a category mismatch for me for the graphics use cases needing more expressivity -- simple strides exist in other languages and enjoy use, despite lacking the extra expressivity [15:43:26.0000] gibson042: that is neither valid nor invalid now (per spec), and could be made invalid without breaking anyone (I suspect) [15:43:30.0000] keith_miller: so maybe the high-order bit here is actually how much implementation burden is there, given that this is intended to be a smallish, incremental ergonomic win [15:44:01.0000] Bakkot: hm, that would be another deviation from Identifier though [15:44:15.0000] right. So rejecting `/(?<\ud835\udc9c>.)/` can only be on the basis of treating it as two code points [15:44:29.0000] keith_miller: that is, i'm pushing back against the framing that satisfying all graphics use cases is a pre-req [15:45:09.0000] mathiasbynens \ud835\udc9c is not legal in identifiers, is it? [15:45:12.0000] which it is not in the same regex outside of naming a group [15:45:15.0000] Bakkot: no [15:45:21.0000] mathiasbynens wait which "no" [15:45:43.0000] "no, it is not legal" or "no, you're mistaken, it is legal" [15:45:50.0000] Bakkot: escaped surrogate pairs in identifiers == not valid [15:45:54.0000] `\ud835\udc9c` is not a valid IdentifierName because it is interpreted as two code units, neither of which are in a valid class [15:46:02.0000] You can already access a non-BMP property using foo["\ud835\udc9c"]. [15:46:16.0000] shu: I'd roughly agree with that assessment but I phrase it as the cost is roughly known/fixed but there may be enough use cases to justify it [15:46:22.0000] (it's v late and i've been v difficult here, apologies and cheers for bearing with me so far) [15:46:28.0000] err, two code *points* [15:46:30.0000] keith_miller: yeah, point taken [15:46:40.0000] if it were interpreted as a surrogate pair for a single code point, then it would be a valid identifier [15:46:45.0000] RegExes should work like strings [15:46:56.0000] I'm not trying to say you have to solve all use cases only that there are still a lot of use cases that are not very ergonomic anyway [15:47:02.0000] which is what happens inside strings and inside regular expression literals outside of naming capture groups [15:47:06.0000] with this api* [15:47:19.0000] keith_miller: right, so it comes down to how big is the set of use cases that would be made ergonomic, and how much work do we have to do for it [15:47:28.0000] I just checked and the current spec only allows unicode escapes in NGC Identifiers for Unicode. And it allows both \uXXXX\uXXXX and \u{XXXXX} for NCG identifiers. [15:47:29.0000] yeah [15:47:40.0000] I think we're on the same page [15:47:50.0000] keith_miller: which are both pretty valid; all the use cases on the explainer now are graphics, and if graphics folks are like "lol no" then that's just bad motivation. if we can't find better ones then yeah, just do it in user code [15:48:20.0000] wsdferdksl: regexes have different concepts of what constitutes a "character" depending on the `u` flag, so strings/regexps don't map nicely [15:48:41.0000] msaboff: the current spec has an early error for "the SV of RegExpUnicodeEscapeSequence", which is not an operation which is defined [15:48:42.0000] I'm talking about non-u regexes [15:48:50.0000] msaboff: sorry, what is NCG? [15:48:55.0000] named capture group [15:48:59.0000] ah duh [15:49:01.0000] Both those and strings work with 16-bit chunks [15:49:11.0000] Named Capture Group [15:49:15.0000] regexes of both kinds recognize surrogate pairs as single code points outside of naming capture groups [15:49:25.0000] No [15:49:36.0000] no, look at atoms [15:49:44.0000] character classes too [15:49:54.0000] gibson042 in practice pretty much in reality no [15:49:58.0000] gibson042: e.g. \uLEAD\TRAIL{2} [15:50:57.0000] https://mathiasbynens.be/notes/es6-unicode-regex has some examples [15:51:40.0000] this is veering into semantics now; non-Unicode regexes operate on UTF-16 code units [15:52:05.0000] lol [15:52:22.0000] wsdferdksl mathiasbynens gibson042: I don't think we're likely to resolve this today. are you all OK with the committee approving the current spec, including this oversight, as the candidate for 2020, and trying to resolve this later? [15:52:32.0000] No [15:52:41.0000] We should resolve this [15:52:41.0000] I am, since it's not new anyway [15:52:49.0000] Bakkot: I see no rush tbh. I'd rather resolve it properly [15:53:13.0000] wsdferdksl: given that we don't appear to be close to consensus, how can we resolve it? [15:53:20.0000] I guess we could call a formal vote for this question [15:53:27.0000] There is only one solution that works for ASCIIfiers, and it's not difficult to do. [15:53:30.0000] let's keep the spec as-is until we can get proper consensus (which doesn't have to be in this meeting imho) [15:53:51.0000] Bakkot: Is the "SV value of RegExpUnicodeEscapeSequence" confusing in the context of a Unicode RegExp? [15:53:56.0000] wsdferdksl: there are two solutions: we could make \u{...} work in NCG in non-u regexps [15:53:58.0000] msaboff It's not defined at all, yes [15:54:02.0000] that's why this issue comes up [15:54:20.0000] I don't see why we don't have consensus. It's not like people are going to be writing this kind of stuff. [15:54:27.0000] well, we don't [15:54:41.0000] Why not? [15:54:52.0000] people feel strongly about consistency with identifiers, mostly [15:55:08.0000] How is that relevant? [15:55:22.0000] It's not like people are going to be writing this kind of stuff. [15:55:23.0000] wsdferdksl: is this your first meeting? [15:55:26.0000] wsdferdksl: why don't we make \u{...} work _only_ in NCG in non-u regexps? that way we don't expose the unfortunate concept of surrogates to more places in the language [15:56:00.0000] "it adds *even more* complexity to an already overwhelming part of the language, and does so for very little benefit IMO" [15:56:20.0000] That would be gratuitously confusing. Once again, it's not like folks are going to be writing this stuff by hand. [15:56:37.0000] I'm stepping out for a bit, be back later [15:57:01.0000] gibson042: can't you say the same thing about allowing individually-escaped paired surrogates in groups? [15:58:25.0000] i'm heading off, should've gone to bed hours ago. thanks for bearing with me y'all. and Bakkot, I really appreciate your work on trying to fix this spec bug, one way or another -- thanks! [15:58:41.0000] mathiasbynens thanks for engaging; sleep well [16:00:20.0000] Bakkot How do you reconcile that with "SV of UnicodeEscapeSequence"? The only difference compared to RegExpUnicodeEscapeSequence is that RegExpUnicodeEscapeSequence includes \uXXXX\uXXXX. [16:01:10.0000] xs uses freeze [16:01:19.0000] Regexes are confusing. This is an edge case. My preference is to make `/(?<\u{1d49c}>.)/ == /(?<π’œ>.)/`. I think it's more important to have consistency with language syntax than consistency in behavior. If someone is surprised by the behavior, we have a reason for it. [16:01:22.0000] msaboff: "SV" is an operation which is not defined for RegExpUnicodeEscapeSequence [16:02:13.0000] but it is defined for UnicodeEscapeSequence [16:02:35.0000] wsdferdksl: to be concrete, of the following four regular expressions literals, which do you think ought to be legal? /(?<\ud835\udc9c.)/ /(?<\u{1d49c}>.)/ /(?<\ud835\udc9c.)/u /(?<\u{1d49c}>.)/u [16:03:02.0000] 4 min break! [16:03:02.0000] btw https://arai-a.github.io/ecma262-compare [16:03:05.0000] Bakkot: 0, 2, and 3. [16:03:11.0000] Bakkot Maybe the fastest path to victory is defining "SV of RegExpUnicodeEscapeSequence" [16:04:11.0000] The rationale being that's those three out of the four are "legal" if you don't enclose the escapes inside (?<>). [16:04:30.0000] msaboff: yeah, but there's normative implications and we have to get people to agree on the normative behavior [16:04:37.0000] ljharb: bradleymeck: https://nodejs.org/api/vm.html#vm_constructor_new_vm_sourcetextmodule_code_options [16:04:43.0000] i just remembered this is a thing [16:05:10.0000] non-stage 4 features, in my runtime :gasp: [16:05:22.0000] we can deprecate it [16:05:30.0000] actually we don't even need to do that [16:05:33.0000] its still experimental [16:05:39.0000] wsdferdksl: would you be OK with /(?<\u{1d49c}>.)/ being legal? I would prefer it to be legal just for simplicity of tooling, personally [16:05:47.0000] Bakkot: do you think that any implementation is doing something different than the obvious? [16:05:57.0000] msaboff yup [16:06:00.0000] both you and chrome are [16:06:19.0000] It's a bit more complex, but I wouldn't object to that, if the other three were also legal. [16:06:19.0000] Let me look at your slides again... [16:06:42.0000] msaboff in particular, the "obvious" thing would not depend on the presence of the `u` flag, but JSC and V8 both do [16:07:00.0000] ok break time is over! [16:07:06.0000] It wouldn't simplify the tooling because you can't use \u{} outside of (?<>) [16:08:22.0000] wsdferdksl it depends on the tooling. I could imagine tooling which parses regexes and re-serializes them, and being able to use the same serialization logic for group names for both `u` and non-`u` regexs is slightly simpler. [16:08:27.0000] but yes it's a very small win [16:09:07.0000] But the spec requires the u flag to get to the RegExpUnicodeEscapeSequence production. I think we comply in light of the u flag. Not that a patch landed last night in JSC that deals with this. [16:09:24.0000] does anyone know the rationale for using the m suffix for decimals? (as in .2m) [16:09:37.0000] as opposed to? [16:09:47.0000] haha, yes, it seems pretty arbitrary [16:09:48.0000] msaboff the spec does not require the flag, in my reading? [16:09:50.0000] .2d? [16:10:03.0000] 0x34d [16:10:15.0000] f means float, i means imaginary, etc [16:10:15.0000] oh sure, probably shouldn't be a-f [16:10:26.0000] why does m mean decimal though? [16:10:32.0000] that i don't know [16:10:37.0000] is it like two n's, smushed together? [16:10:39.0000] like a fraction? [16:10:39.0000] deciMal [16:10:41.0000] you can't spell decimal without m [16:10:41.0000] https://github.com/tc39/proposal-decimal/#why-are-literals-m-why-not-d [16:10:55.0000] shu: true that [16:11:11.0000] _M_oney [16:11:17.0000] lol [16:11:18.0000] oooo [16:11:28.0000] that's how the twitter teachers will teach it 100% [16:12:26.0000] https://tc39.es/ecma262/#prod-RegExpUnicodeEscapeSequence has the U suffix and all rules that evaluate to it require U to be true. [16:12:59.0000] yes! I love the idea of #{ numerator, denominator } [16:13:09.0000] msaboff the `[U]` suffix means it's a parameter, not a requirement [16:13:25.0000] The +U means it must be true [16:13:29.0000] benjamn: in a decimal type n/d is just that [16:13:39.0000] Rationale for C#'s use of `m` (tldr; it was the next best letter in `decimal`): https://stackoverflow.com/a/977562 [16:14:08.0000] msaboff which +U? [16:14:13.0000] definitely better `m` than `i` or `l` [16:14:14.0000] suggestion for decimal: `#{ mantissa, scale }` where mantissa is a BigInt [16:14:30.0000] what is scale [16:14:32.0000] devsnek: oh yes, I'm not suggesting that tuples would automatically serve all the decimal use cases [16:14:38.0000] scale is a power of 10 [16:14:43.0000] oh exponent ok [16:14:59.0000] `#{ 123n, -2 }` is 1.23 [16:15:03.0000] Every RHS rule for https://tc39.es/ecma262/#prod-RegExpUnicodeEscapeSequence [16:15:08.0000] 1.23m is 1.23 [16:15:17.0000] msaboff: `[~U] u Hex4Digits` [16:15:42.0000] so not every RHS rule [16:16:02.0000] That is not valid for NCG Identifiers. [16:16:20.0000] How not? [16:16:44.0000] GroupName is `GroupName[U] :: < RegExpIdentifierName[?U] >` [16:17:56.0000] and then `RegExpIdentifierName[U] :: RegExpIdentifierStart[?U]` -> `RegExpIdentifierStart[U] :: \RegExpUnicodeEscapeSequence[?U]` [16:18:32.0000] In your mind, how does the character value definition for RegExpUnicodeEscapeSequence in https://tc39.es/ecma262/#sec-patterns-static-semantics-character-value answer the SV question? [16:19:24.0000] rbuckton: oh wow, I did not expect "the [first good] letter in decimal" to be such a persuasive argument [16:19:39.0000] https://tc39.es/ecma262/#sec-patterns-static-semantics-character-value gives semantics for CharacterValue for every RHS that RegExpUnicodeEscapeSequence produces [16:19:42.0000] but d, e, c, and i are all quite problematic… so yeah [16:20:20.0000] Only the \uHexDIgits is valid to NCG ids in non-u RegExps [16:20:47.0000] sffc: that sounds a lot like a reduced form of Rationals [16:20:48.0000] in C#: `d`-double,`e`-exponent, `c`-char, `i`-integer, `l`-long. Only other option would have been `a` [16:21:38.0000] Therefore we (currently) can't have a non-BMP character in a NCG id for non-u RegExps. Agree? [16:21:40.0000] I'm currently pursuing a struct/value-type proposal with syntax for operator overloading. [16:22:14.0000] And we (currently) can have non-BMP codepoints in NCG ids for u flagged RegExps. [16:22:44.0000] can we get a tc39-regex channel [16:22:49.0000] (/s) [16:22:54.0000] So your slide #10 is conforming. [16:22:56.0000] msaboff we can have a non-BMP character in a NCG id as two `\uHex4Digits`. or rather, the spec does not say whether or not we can ahve that. [16:25:11.0000] The way I read the spec is we must interpret two `\uHex4Digits` as two individual codepoints for non-unicode RegExp NGC ids. The must each be appropriate ID characters depending on their position. [16:25:51.0000] They might be dangling surrogates, but that would be a syntax error as they wouldn't be ID codepoints. [16:26:13.0000] msaboff: that's how I originally expected non-u regexps to work [16:26:20.0000] The "must each be appropriate ID characters depending on their position" bit is the part where the current specification does not provide an answer. [16:26:45.0000] but, yes, that would be the smallest delta from the current specification (and is what my current PR does) [16:27:21.0000] First position IDStart and following codepoints IDContinue [16:27:28.0000] I think we need an official "stage 1" proposal repo to investigate operator overloading in all of its various forms, and as a single place to collect the various requirements and concerns. [16:27:50.0000] https://github.com/tc39/proposal-operator-overloading [16:28:08.0000] ^ thanks :) [16:28:23.0000] i'm really not a fan of that proposal though [16:28:42.0000] Bakkot I think the current spec DOES provide the answer for the non u flag NCG id case. [16:28:50.0000] devsnek: yes and no. That proposal is currently very specific to the constructor-based overloading approach. I've already expressed concern over this approach from a static analysis/tooling perspective. [16:29:05.0000] if js had operator overloading i'd want it to be all dynamic and whatnot [16:29:07.0000] at stage 1, proposals are about solving problems [16:29:16.0000] msaboff: it doesn't tell you what "SV of UnicodeEscapeSequence" is, so you can't tell if it satisfies "the UTF16Encoding of a code point matched by the UnicodeIDStart lexical grammar production" [16:29:50.0000] I may disagree with what is says and be sympathetic to what you want, but that is different than how I read the current spec. [16:30:43.0000] What does the end of section https://tc39.es/ecma262/#sec-static-semantics-sv say to you about "SV of UnicodeEscapeSequence [16:31:26.0000] msaboff: sorry, my previous message should read "it doesn't tell you what the SV of RegExpUnicodeEscapeSequence is" [16:31:38.0000] msaboff: the relevant rule is "Early Errors: RegExpIdentifierStart[U]::\RegExpUnicodeEscapeSequence[?U] It is a Syntax Error if the SV of RegExpUnicodeEscapeSequence is none of "$", or "_", or the UTF16Encoding of a code point matched by the UnicodeIDStart lexical grammar production." [16:31:39.0000] It feels like we are being pulled off topic a bit [16:31:53.0000] (comment regarding discussion in the video) [16:33:06.0000] mfw 1n is not equal to 1 [16:33:30.0000] did someone remove my queue item? [16:33:36.0000] why do they have relational equality but not absolute equality [16:34:24.0000] devsnek: `===` does not do type coercion [16:34:24.0000] Bakkot: Back to what I said earlier, I think that is what the end of https://tc39.es/ecma262/#sec-patterns-static-semantics-character-value describes. (Even though it talks about the CharacterValue, which is a String with one code point.) [16:34:32.0000] Bakkot: i'm not saying type coercion is needed [16:34:57.0000] msaboff: that defines CharacterValue, not SV [16:35:03.0000] 1n and 1 both exactly represent the mathematical value 1 [16:35:15.0000] my point is that "SV of RegExpUnicodeEscapeSequence" is not defined [16:35:28.0000] yes, the smallest delta would be to use CharacterValue instead; that's what my current PR does [16:35:34.0000] but it does not, currently, use CharacterValue instead [16:36:23.0000] IMHO, SV is the obvious string with a single CharacterValue. [16:36:47.0000] If we added such a rule, would that be suficient? [16:37:36.0000] Yes, the problem is that the absence of semantics here means that such a decision would be normative [16:37:41.0000] which is why I brought it to committee [16:37:58.0000] and then people had opinions about which semantics to choose [16:39:38.0000] msaboff: although, that said, that decision would mean it was impossible to render `/(?<π’œ>.)/` as ascii [16:39:41.0000] Make your PR "the SV of RegExpUnicodeEscapeSequence is the one character string of the CharacterValue of RegExpUnicodeEscapeSequence." and make it normative. [16:39:50.0000] which also does seem legitimately bad [16:40:19.0000] That is a separate change to the RegExp section. [16:40:34.0000] akirose: Can we post the meeting agenda for June? I meant to put https://github.com/tc39/ecma262/pull/1912 on the agenda but I thought PRs were automatic... I don't want to forget about it lol [16:40:55.0000] keith_miller: i'll do that [16:41:02.0000] great thanks! [16:41:04.0000] Bakkot You need to change how RegExpIdentifierStart and RegExpIdentifierPart are defined [16:41:26.0000] yeah [16:41:43.0000] I am reasonably sure I can spec any possible semantics here if we can agree on the semantics [16:41:50.0000] I just want os to agree on one thing [16:42:29.0000] we may finish at 17:09 if this runs for the full 30 minute slot [16:43:11.0000] πŸŽ‰ [16:44:38.0000] ljharb: i may be interested in helping [16:44:57.0000] how exciting [16:45:04.0000] i may be interested in commenting on the github issues [16:46:12.0000] am I correct in assuming `a ??= b ??= c` would mean `a ?? (a = (b ?? (b = c)))`? [16:46:22.0000] devsnek: I might be interested in the complement of that [16:46:23.0000] that's how you open the js portal [16:47:10.0000] benjamn: yep looks right [16:47:28.0000] (just without the double-evaluations) [16:47:41.0000] rkirsling: ahh good point [16:47:42.0000] i think it would be `a = a ?? b ?? c` ? [16:47:50.0000] no [16:47:56.0000] assignment chains return the most right-hand side [16:48:00.0000] s/return/use/ [16:48:14.0000] ah ok [16:48:46.0000] `let _v = c; b ??= _v; a ??= _v;` [16:48:47.0000] benjamn: I believe you are correct [16:49:41.0000] devsnek: is there a way to avoid evaluating c in that, if a or b is already defined? [16:49:56.0000] https://babeljs.io/repl/#?browsers=&build=&builtIns=false&spec=false&loose=false&code_lz=IYAg_GC8IEblIDGQ&debug=false&forceAllTransforms=false&shippedProposals=false&circleciRepo=&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=stage-1&prettier=false&targets=&version=7.9.0&externalPlugins= [16:50:18.0000] I don't believe `b` is set if `a` short-circuits [16:50:18.0000] benjamn: oh you're right it doesn [16:50:24.0000] doesn't evaluate the right hand side [16:50:29.0000] Yah [16:50:34.0000] i forgot about that [16:50:34.0000] time pressure isn't good [16:51:31.0000] jridgewell: that reduces to [16:51:39.0000] (sorry premature send) [16:52:53.0000] `a != null ? a : a = b != null ? _b : b = c;` [16:53:10.0000] yes [16:53:28.0000] (s/_b/b/) [16:53:29.0000] if null there means nullish (including undefined) [16:53:33.0000] Yes [16:53:35.0000] ystartsev: awesome, thanks! i'll post an issue shortly and tag you [16:53:44.0000] ljharb: great thanks [16:54:22.0000] https://engine262.js.org/#gist=b972418f6ec2e52a7c9c711eda60a446 [16:55:00.0000] devsnek: cool that's what I would hope [16:55:15.0000] chained logical assignment seems entirely… logical [16:55:30.0000] keith_miller: june agenda is pushed, feel free to commit directly to it [16:55:31.0000] except when the assignment target is const /s [16:55:44.0000] oh shit that didn't get brought up did it [16:56:01.0000] or did I just look away and miss it? [16:56:09.0000] i don't remember it happening [16:56:10.0000] rkirsling: it didn't, no [16:56:31.0000] 😬 [16:56:32.0000] like [16:56:41.0000] I don't expect it to change consensus [16:56:47.0000] but it deserves public mention [16:57:08.0000] I should've thought to bring it up myself [16:57:10.0000] ...oops [16:57:15.0000] yeah same [16:57:22.0000] if we don't ship a spec, the latest spec will still have the bug [16:57:39.0000] littledan: put that on the queue [16:57:42.0000] ^ [16:57:43.0000] ^ [16:58:04.0000] eh I'm fine just leaving it here; the day's almost over