2021-04-07 [11:00:14.0000] holy crap tc39 is in < 2 weeks [11:00:27.0000] this new schedule is a lot [11:15:50.0000] 😱 [12:55:32.0000] deadline for advancement eligibility is in like two days and we have about 1 day's worth of content on the agenda so far: https://github.com/tc39/agendas/blob/master/2021/04.md [12:56:46.0000] surely more things will roll in on friday, and also there's likely a number of non-advancement things that don't need the deadline [13:20:59.0000] oooh class fields going for stage4 [13:21:06.0000] that will be fun [13:25:55.0000] gsathya: any idea how chrome's implementation of `#x in obj` is going? :-D [13:26:48.0000] test262 tests still haven't landed, so i wouldn't be surprised if it's not going yet [13:27:37.0000] https://chromestatus.com/feature/5006138707804160 [13:27:45.0000] says shipping in 91 [13:27:57.0000] score, ty [13:29:09.0000] gsathya: which v8 version might that be in? (so i can poke node) [13:30:06.0000] 9.1 [13:30:57.0000] awesome thanks 2021-04-09 [09:16:32.0000] Reminder: if anyone wants to try out the new Jitsi AV in preparation for plenary, please join us in 15 minutes: https://github.com/tc39/Reflector/issues/366#issuecomment-816794278 2021-04-11 [13:38:59.0000] can plenary be added to the tc39 calendar? [13:56:46.0000] devsnek: it's already on there [13:57:05.0000] it's marked "all day" tho, let me update it to the actual times [13:57:59.0000] k, done [14:00:07.0000] oh cool it shows up now [14:00:08.0000] thx [14:02:04.0000] it was surely there before, just as a bar on top of all the days [14:02:16.0000] i went ahead and updated all the 2021 meetings so they're appropriate timed and timezoned tho 2021-04-16 [19:56:23.0000] https://github.com/tc39/proposal-async-iteration should be archived i think [21:23:15.0000] devsnek: yeah there's a number of stage 4 repos that need it; as soon as the chairs give me the goahead i'll be auditing all of them 2021-04-18 [12:13:23.0000] Could I get a one-line review here please https://github.com/tc39/notes/pull/116 [12:24:33.0000] robpalme: lol i'm trying but it seems like a github bug rn, no JS errors but the "review changes" dropdown won't drop [12:24:50.0000] it won't even let me comment [12:33:55.0000] k got it [12:36:26.0000] i was about to say, i'd love to invoke myles to fix the github website but last i checked he was on vacation ;-) [12:36:35.0000] thank you [12:36:50.0000] np [12:36:58.0000] may have just been my browser, i dunno 2021-04-19 [06:17:47.0000] good morning/afternoon/evening all [06:19:27.0000] The Jitsi video conferencing for today's meeting has a passcode that, for some reason is limited to 10 characters. You can find this once you use the Entry form on the Reflector post (see IRC Topic). [06:38:44.0000] has anyone tried to join the video call yet? I am the only one on. [06:45:27.0000] Istvan has joined [07:09:35.0000] 8x8 isn't letting me in, did we fall back to Teams? [07:09:45.0000] no - we are using Jitsi [07:09:53.0000] 40 people are in the call [07:10:21.0000] the password is stated in the entry form [07:10:33.0000] it's rejecting the passcode :\ [07:10:46.0000] trim it to 10 letters [07:10:51.0000] chacters [07:11:04.0000] (I updated the form to explain this) [07:11:39.0000] awesome, thanks! [07:11:40.0000] #tc39-editors should be on this list [07:11:58.0000] do you mean #tc39-editor-group? [07:12:02.0000] see? [07:12:06.0000] (i've mistakenly joined tc39-editors on many an occassion) [07:12:42.0000] I just have it auto-join since this is the only thing I use IRC for [07:13:55.0000] irccloud just remembers which channels i'm in ¯\_(ツ)_/¯ [07:16:17.0000] it's kicked me out of stuff before due to maintenance net splits, but that's about it i guess [07:16:57.0000] Daniel Rosenwasser will be helping us to facilitate this meeting. [07:23:03.0000] someone extra seems to have their audio on [07:25:15.0000] i think i see frank on two different cameras [07:30:46.0000] the burden of running the VC system falls on the chairs in practice, not the hosts, as the meetings are fully remote [07:31:55.0000] I definitely think Felienne deserves an award. Maybe we can make a TC39-level award if Ecma refuses to recognize her great work. [07:33:07.0000] +1 [07:37:15.0000] i feel pretty strongly about anba as well [07:37:28.0000] so, this is very sad [07:40:23.0000] I think that we put forward andre and jordan this timem [07:40:45.0000] istvan did mention "2" [07:47:30.0000] yes, i believe this is what the situation was [07:47:54.0000] so this is very unfortunate, but i would be happy to see them both nominated for the first tc39 recognition award [08:05:34.0000] https://github.com/tc39/ecma402/wiki/Proposal-and-PR-Progress-Tracking [08:09:14.0000] If anyone has any concerns or questions about Temporal at Stage 3, please ask [08:10:35.0000] littledan: what kind of data is needed to implement temporal [08:11:12.0000] probably mostly the TZDB (if you want it to work well) [08:11:30.0000] sounds simple [08:13:18.0000] I mean, if you're making a JS meta-circular interpreter, you can reverse-engineer the data from Intl [08:15:02.0000] if the data can change i prefer to bundle a separate version so it works even in older engines [08:16:12.0000] slides: https://docs.google.com/presentation/d/13s8STWY1zVab3KRK62Q0mhWeKQ2aLKS1wTTKgyJe7iQ/edit#slide=id.g6e7d7a6a09_0_93 [08:16:48.0000] https://docs.google.com/presentation/d/13s8STWY1zVab3KRK62Q0mhWeKQ2aLKS1wTTKgyJe7iQ/edit#slide=id.g6e7d7a6a09_0_98 [08:17:22.0000] devsnek: there is a node package with the ICU data btw [08:18:56.0000] ryzokuken: do you mean the one that node can dynamically load? [08:19:18.0000] yes [08:19:21.0000] the main issue is not the raw data, it's the processing of it [08:19:30.0000] there's also a module for that haha [08:19:35.0000] o.O [08:19:58.0000] devsnek: I miss a thread of something to discuss about Test262 for stage 3 before a meeting [08:20:58.0000] devsnek: https://www.npmjs.com/package/cldrjs [08:21:48.0000] I don't think the way the topic about Test262 is being addressed is ideal. I'd like to make sure it does have space for proper feedback from people historically contributing to the tests [08:22:34.0000] leobalter: i figured an ideal place to gather that was here, where everyone gathers in one "room" [08:23:12.0000] sffc: something to follow up on? [08:23:17.0000] and for a very quick feedback: In general I'm against Test262 a place for tests before stage 3. It's a matter of convenience for champions vs burden of maintenance. [08:24:03.0000] devsnek: the reality is that most Test262 contributors (not limited to me, Rick, or Mike Pennisi) are not attending TC39 meetings [08:24:24.0000] leobalter: what if they are not added to the test262 repo but maintained in just the proposal repo instead? [08:24:47.0000] yeah we should just say "tests" rather than "test262 tests" [08:25:18.0000] one thing i was going to suggest was having an open pr with tests, even if they aren't merged yet [08:25:31.0000] just something that implementors can go off of [08:25:36.0000] I understand the concerns but it's also really useful for implementers to have tests ready I feel [08:25:39.0000] yeah [08:25:46.0000] well, you can have Test262 tests today that are not in Test262's main branch. Saying the tests are good, done, ready becomes way more subjective such as saying tests are available for browsers to import too [08:26:09.0000] open prs is not a solution if they are required to be reviewed [08:26:36.0000] otherwise one could just open a PR with anything and say there is an open PR [08:27:21.0000] yeah there's lots of choices and things to consider [08:27:32.0000] so i put a big chunk of time on the schedule [08:27:34.0000] there is a lot of problems with tests for stage 2, usefulness for implementers is something else I consider complex, there is a lot of caveats [08:27:42.0000] i can make it longer if you want [08:27:59.0000] devsnek: full disclosure I don't feel comfortable with that topic [08:28:30.0000] because I know a big majority will just throw ideas on how Test262 would be more convenient. This happens all the time [08:28:50.0000] the same amount of cheered suggestions is opposed to commitment in maintenance [08:29:20.0000] I don't feel comfortable with the discussion being held before an open github thread [08:29:24.0000] without a summary [08:30:04.0000] omg what is the japanese approximate symbol? now I need to know [08:30:26.0000] littledan: lol I asked the same thing on #temporaldeadzone [08:30:40.0000] since it's early stage we can't even check... [08:34:00.0000] leobalter: you mean on the test262 repo? i'm not sure that matches who the tc39 process document applies to [08:35:03.0000] i think from the perspective of maintaining the test262 repo the cost is the same, the tests just get merged sooner, and might actually be written by the people making the proposal because stage 3 is a big carrot [08:36:09.0000] I don't feel comfortable discussing this topic within the dynamics of a chat. My request is to have a proper thread. If TC39 delegates can't commit to that, I'm not gonna expose myself for another Test262 burnout [08:36:15.0000] so I'm done discussing here. Sorry. [08:36:46.0000] halfEven sounds weird but it's really important to counter cascading errors in floating point calculations [08:37:04.0000] for the record, Caio Lima will be championing Decimal going forward :) [08:42:03.0000] leobalter: i'm not planning to ask for any consensus at this meeting, i want to ask members of the committee how they feel about these requirements [08:43:10.0000] happy to discuss additional feedback after the meeting or in a pm or something, it's just unclear to me what you're asking [08:44:05.0000] what's the algorithm shane refered to? [08:44:39.0000] devsnek: I can assure you there is a likely chance people will cheer your suggestion without consideration of the things I pointed out [08:45:02.0000] If I don't attend that discussion, there is a likely chance it will become an echo chamber [08:45:14.0000] but I can insist: the maintenance burden is awful [08:45:26.0000] I'm asking a simple thing: [08:45:44.0000] open a thread in Test262 [08:45:53.0000] this discussion happened several times in the past [08:46:04.0000] let people who maintain Test262 to chime in [08:46:58.0000] AFAIK, Mike Pennisi is the one doing Test262 for v8+Bocoup. There are other people involved. [08:47:30.0000] ok. if members feel like this is something they would feel comfortable with i will open a thread on test262 [08:47:59.0000] but it is still unclear to me what feedback is being gathered in that thread [08:49:09.0000] the feedback is what I'm trying to say so many times [08:49:15.0000] burden of maintenance is very high [08:49:28.0000] Test262 maintenance already causes burnout [08:49:41.0000] your proposal adds a lot of cost on maintenance, a lot [08:49:50.0000] so if it's unclear to you [08:49:53.0000] so like [08:50:11.0000] "do you feel that champions contributing tests earlier would increase maintenance burden" [08:50:48.0000] that's what I hate to be doing. I told I don't feel like answering these questions in a chat. I'm trying to attend the meeting [08:51:07.0000] I'd appreciate an async discussion [08:51:19.0000] but if you really require me to tell you all the dots [08:51:23.0000] I hate this btw [08:51:36.0000] champions can contribute with tests at ANY MOMENT [08:51:42.0000] sorry i just meant is that the question you're wanting to ask, feel free to message me later [08:51:46.0000] to test262 as PRs, to stage 3 [08:52:19.0000] I won't message later in any private capacity [08:53:20.0000] well [08:56:22.0000] it seems like such a requirement (test262 tests before stage 3) would move the friction of "champions or test262 maintainers writing tests" from "before stage 4" to "before stage 3". wouldn't this be the same burden, just moved earlier in the process? or are you worried that this would result in _more_ proposals needing test262 tests, ones that might not otherwise make it to stage 3 - or that proposals will have larger kinds of [08:56:23.0000] change before stage 3, resulting in more test262 churn? [08:57:18.0000] I need to jump to another computer. Jitsi's audio stopped working here [09:00:49.0000] we've had tests rejected from test262 because it wasn't at stage 3 if I recall correctly [09:02:42.0000] ystartsev: that's correct [09:03:15.0000] I can try to illustrate what's the problem, but most people tend to not give a worry about it [09:03:22.0000] (which makes sense now, when the requirement is to add them during stage 3. seems obvious that if we changed the requirement test262 would change their criteria) [09:03:57.0000] I will be at the breakout session if anyone wants to talk about it. [09:06:41.0000] quick reminder: I'm at hubs available if anyone wants to talk about Test262. Apparently I'm the only one there so far. [09:09:48.0000] I have dinner right now [09:10:59.0000] ystartsev: We have a number of ECMA-402 proposals in the works which may require some scrutiny and feedback from a user privacy perspective. At the meeting where the security TG was proposed, I asked if we could include privacy in the charter. Since the TG decided to move forward without including privacy, it just leaves that question unresolved. [09:11:59.0000] On that front, I would personally be happy if there were a dedicated person or set of people to address privacy questions on TC39 proposals. It doesn't need to be a full TG. [09:13:05.0000] right, do we have anyone with that competency on committee? we haven't had a volunteer yet so I am guessing we either don't or we don't have someone with the time... [09:13:46.0000] or, we might have someone who wants to grow in that direction and focus on it? [09:18:10.0000] For Intl Enumeration API, we relied on delegates to outsource the privacy questions. AFAIK, we don't have anyone who regularly attends TC39 with that expertise. [09:31:56.0000] I mentioned this to zibi at some point, but talking to W3C PING when you need such expertise is encouraged [09:32:32.0000] Privacy teams from browsers as well, but hopefully they get looped in regardless when it's appropriate [09:33:07.0000] That sounds like a really good idea [09:33:38.0000] I haven't been much on intl so I don't know all of the discussions there, but I'll try to make sure we have that happening [09:53:15.0000] can someone enable https redirects for tc39.es? i think its just a checkbox on the github settings [10:25:33.0000] true, it feels like a standing ovation [10:28:01.0000] when the staging process was implemented, was there specific logic around the choice of two browsers shipping a feature for stage four? [10:28:20.0000] bnb: it's the one requirement that's vague, because there's no consensus on the specifics [10:28:30.0000] devsnek: sure [10:28:48.0000] I'm wondering specifically if there was assumptions around there being a certain number of browsers who could implement it [10:28:52.0000] bnb: the logic was something like "make sure the feature has been exposed to web reality, and to many users/usage, and to different implementations" [10:28:57.0000] bnb: so yeah that was part of it [10:29:02.0000] bnb: but not every feature requires it [10:34:18.0000] yeah, this feels absurdly unprofessional [10:35:13.0000] 360 wasn't a member when it hit stage 3. not arguing one way or the other [10:36:45.0000] i wasn't a member when the class keyword was chosen to be spelled "class". doesn't mean i could have objected to ES6 on those grounds. [10:37:20.0000] devsnek: I don't think that's the point though. 360 was certainly a member when the agenda item was added, they could still voice this concern in a better way? [10:37:49.0000] we have a whole process around timing constraints for example, which they did not use. [10:45:53.0000] Who is "we"? [10:46:02.0000] in this case, huawei [10:46:06.0000] I see [10:47:54.0000] I think it's more of a UI thing than an optimization thing--how do you represent which class the private name came from [10:48:04.0000] I think there was a Chromium issue about this as well [10:48:09.0000] tbh i'd prefer that the inspector not show private fields at all [10:48:13.0000] but the inspector is utterly out of our scope [10:48:28.0000] agree that it's out of scope. I think it's useful to show them for debugging, though [10:49:30.0000] drousso: excellent example re dom element, ty [10:49:52.0000] 👍 [10:50:00.0000] (shameless plug too cause I added that feature :P) [10:55:44.0000] I can tell so much how I agree with BT [10:56:09.0000] Can we extend the timebox by 30 minutes, given that we don't have anything afterwards? [10:56:15.0000] +1 [10:56:59.0000] we can be honest and just say we're moving forward without consensus [10:57:39.0000] IMO it's fine for the chairs to do that [10:58:23.0000] the process document specifies what is in scope for blocking Stage 4 [10:58:55.0000] we are moving forward without objections that meet the requirements BT just mentioned [10:59:01.0000] exactly [11:00:40.0000] ystartsev: nit pick: they've been at tc39 for longer than an year [11:00:45.0000] ystartsev: well said [11:00:48.0000] +1, this cannot be stated sharply enough [11:00:53.0000] +1 [11:00:58.0000] +1, ofc [11:07:52.0000] akirose: bterlson: my hat off to the chair group for navigating this, chapeau [11:11:07.0000] =1 [11:11:09.0000] +1 [11:11:12.0000] +1 [11:12:28.0000] For reference, TC39's process scopes which kinds of arguments can block Stage 4 consensus in https://tc39.es/process-document/ in the paragraph starting with "Given that consensus on Stage 3 means..." [11:13:42.0000] 👏 [11:13:47.0000] As a browser implementer, I will say that stage 3 must retain its significance [11:14:08.0000] ^ [11:14:17.0000] If we need more design space, then it may make sense to add a stage [11:14:31.0000] but there _must_ be a stage for implementers to do their work, and it _must_ be a protected stage [11:14:35.0000] that has been stage 3 historically [11:14:35.0000] I can do my funding process discussion in 15 minutes, I think [11:14:46.0000] but, it's lower priority than other agenda items [11:15:01.0000] akirose: ^ [11:15:23.0000] YESSSSSSS hero [11:28:42.0000] I have to run pick up a family member; will leave the bot running but if it dies I am sorry [11:47:39.0000] I consider our request for typesetting support a complete failure [11:47:54.0000] yes [11:48:58.0000] i'm still really confused [11:49:02.0000] did they say no? [11:49:09.0000] or did they say "yes but with these absurd constraints"? [11:49:28.0000] my read was they said "here's a one-off approval with these absurd constraints, which requires more work from you" [11:49:29.0000] the latter [11:49:50.0000] while the whole point was "we'd like to produce a good printed thing for _you_, ecma, since you like to archive, help us help you" [11:50:08.0000] right [11:50:13.0000] yikes [11:50:34.0000] not sure how we can make it clearer "pdf quality will not improve until you agree to our request verbatim" [11:55:16.0000] we contacted companies that provide exactly this service we are looking for [11:55:33.0000] they produce PDF for print layout and epub/mobi for ereader 2021-04-20 [06:46:52.0000] Jitsi video conferencing is now open. Meeting starts in 13 mins. [07:14:57.0000] Is there a way to get rid of the #&$(*!@#(* buttons that the video conference software displays on top of the slides? [07:16:06.0000] removing the mouse cursor from the window should do the trick [07:17:46.0000] rricard: It doesn't. They're always there. Makes slides unreadable. [07:18:10.0000] I would try clicking in the window and removing then [07:19:31.0000] rricard: Tried that. Clicking in the window doesn't do anything. [07:19:55.0000] well I don't know, I do use the electron client maybe it has the feature [07:28:19.0000] wsdferdksl make your window taller [07:41:11.0000] wsdferdksl: paste this in your console: [07:41:13.0000] ((a) => a.parentNode.removeChild(a))(document.getElementsByClassName('toolbox-content')[0]) [07:55:33.0000] isn't Intl effectively all optional? why do we care that much about data size? [07:57:07.0000] I don't think it's optional for browsers? [07:57:13.0000] its not optional for browsers [07:58:15.0000] michaelficarra: who's "we"? the committee? [07:58:22.0000] shu: yes [07:59:05.0000] i wanted to add `\U{character name instead of codepoint}` but browsers were against it due to size [07:59:27.0000] ystartsev: Bakkot: The APIs are not optional, but the data set can be effectively empty, right? There should be no conformance issue. [07:59:48.0000] what would be the point of that [07:59:55.0000] yeah conformance is not a goal for products [07:59:58.0000] that's what node did for years [08:00:05.0000] intl but all the intl apis return garbage [08:00:52.0000] well, that's a little overgeneralization. but conformance is never prioritized over actually providing useful APIs [08:00:52.0000] lol https://gc.gy/86635848.png [08:00:55.0000] because then we are saying, as a standards body, "if you want to provide this functionality, here is how you provide it. If it is too costly, you don't have to provide anything." [08:01:31.0000] michaelficarra: it in no way follows from that size doesn't matter [08:01:48.0000] you still want to make an effort to minimize cost so providing it is more likely [08:02:25.0000] also we should not standardize things which no one is going to ship [08:02:39.0000] or, worse, that they're going to ship in a form which is useless [08:05:01.0000] on the emoji names example, development time tooling could "support" the API and output a replacement [08:05:13.0000] I dunno, seems not entirely useless to standardise these things [08:05:51.0000] standardizing a thing which has runtime implications but is only used at build time would be... strange [08:06:25.0000] there have been suggestions of having a build-time specification for js [08:06:30.0000] not sure how i feel about that but [08:06:52.0000] it would enable this sort of thing in one way [08:08:22.0000] I generally feel like there should be implementations before a standard [08:08:45.0000] like if webpack or whatever wants to add build-time stuff and other people want to interop with that, then it would be the appropriate time to standardize [08:09:17.0000] but the implementations are the important part, we can't just summon them from the void by saying "wouldn't it be neat if something existed with these semantics" like happens with browsers [08:09:46.0000] yeah i think my perspective on that is that its so local that there would never be a need to standardize. you can always add `devsneks-cool-unicode-names-transform` to your package.json [08:10:38.0000] michaelficarra: sorry my attention was split [08:10:52.0000] sorry is this speaker "MD"? for the notes [08:11:59.0000] current speaker is Markus Scherer [08:12:01.0000] Bakkot: MWS [08:12:10.0000] thanks [08:12:32.0000] other speakers in this topic are MB and MED [08:14:44.0000] MED hasn't talked yet, right? [08:15:29.0000] yeah pretty sure he hasn't talked yet [08:17:55.0000] devsnek: https://gist.github.com/leobalter/16364bb167633cb3cb31e0f95e160a2a [08:18:49.0000] I had the chance to quickly discuss the topic with Rick. He did not review this gist but I believe I captured my thoughts there. [08:19:36.0000] leobalter: thanks for the writeup [08:20:19.0000] saying that, I'm sorry the discussion got heated from my side and I got off the rails yesterday. I'd appreciate to be part of the discussion, but that's not an excuse for being aggressive. [08:24:29.0000] no hard feelings... i'm grateful for your input [08:30:13.0000] devsnek: PTAL again, I included a note about coverage + engine262 [08:30:51.0000] 👍🏻 [08:30:52.0000] this is along the lines of the "nothing can casefold to ASCII" guarantee [08:31:18.0000] we just have to trust the Unicode consortium to not do stupid things [08:32:08.0000] well, we don't just have to trust, we can ask them to write down that they won't [08:32:10.0000] and then trust [08:34:14.0000] Instead of having to trust, why no use syntax to denote the type of a property and with what contructs if can be used? [08:34:34.0000] msaboff: eh, they both work in practice though [08:35:31.0000] sounds like Thomas hasn't written a parser [08:35:43.0000] who is thomas [08:35:46.0000] for the notes [08:35:53.0000] we already need Unicode data for ID_Start, ID_Continue, WSP, etc [08:36:13.0000] Bakkot: TLY [08:36:15.0000] thanks [08:36:24.0000] I don't know who they represent [08:36:33.0000] Evernote apparently [08:36:36.0000] We require Unicode data for all the Unicode related properties. [08:36:52.0000] gibson042: Nested [ [ ] ] ] are allowed in the existing lexical grammar. Follow the productions in 12.8.5 [08:37:43.0000] may we pray that 12.8.5 never changes ever [08:52:30.0000] RegularExpressionFirstChar and RegularExpressionChar don't allow unescaped `[` except as part of RegularExpressionClass `[…]`, which itself cannot contain unescaped `]` [08:54:36.0000] so I guess the tokenization doesn't follow the semantic structure, but nonetheless can work [08:55:21.0000] subject to the no-unescaped-`/` constraint [09:03:02.0000] gibson042: This is exactly the reason why I had added the no-unescaped-/ constraint to the proposal here. [09:57:51.0000] we are starting up in 2 mins [10:03:07.0000] can someone take over notes for the next 30 seconds, I want to start a cup of tea [10:03:19.0000] won't be hard, bot likes shu [10:05:42.0000] also someone fill in the last thirty seconds please, my network dropped [10:20:20.0000] who is legendecas, for the notes? [10:21:36.0000] I am having difficulty capturing this comments for the notes [10:22:22.0000] CZW [10:23:55.0000] the example in the survey was absolutely lower case [10:24:14.0000] because I wrote in the exact same concern, even though I don't think the quoted words were mine [10:25:14.0000] i don't think i saw the survey [10:37:03.0000] a script could also call `Object.defineProperty(globalThis, 'GrowableSharedArrayBuffer', { value: globalThis.GrowableSharedArrayBuffer, writeable: false, configurable: false })` at the beginning of the script [10:37:09.0000] so I am hopeful moddable can resolve this that way [10:38:06.0000] (not saying that it needs to happen in the next thirty seconds) [10:38:13.0000] I just don't think it would be especially burdensome for Moddable to resolve this [10:38:31.0000] likely not but it seems reasonable to say that they should get an opportunity to explore that [10:40:36.0000] sure, or at least to quantify that burden so we can better evaluate it as a committee [10:42:06.0000] right [10:42:51.0000] I think Moddable's concern is not just this feature, but the precedent. [10:43:19.0000] right, but if it turns out the precedent isn't actually a problem, that is ideal [10:54:01.0000] For the record -- I didn't say this, but I support the proposal and appreciate all the work you did here to address mozilla's concerns shu [10:54:09.0000] I would really prefer not to wake up at 6:30am if it's avoidable [10:54:28.0000] where was the concern with AggregateError? [10:55:00.0000] I hope we have more time for that [10:56:39.0000] ugh I wish we were calling these immutable arrays and not tuples [10:59:41.0000] i have to go for a bit, just want to be sure I get to say I like this proposal but have concerns about conversation about the names using past forms of verbs (e.g. "I pushed 1 onto the array" .push()? or .pushed()?) [11:00:44.0000] shu: overlooked, really. i'd have brought it up then if it had occurred to me [11:01:35.0000] ljharb: and Realms/Compartments/whatever? [11:01:59.0000] shu: if there's a natural place to nest those, i think we should [11:04:51.0000] ljharb: and to clarify, your position here is purely organizational, right? [11:05:09.0000] shu: yes [11:05:26.0000] shu: it's a bit easier to polyfill etc this way also, but that's a lesser concern since it's already a thing [11:05:42.0000] ljharb: is it? wouldn't it be harder? [11:05:58.0000] what if e.g. SharedArrayBuffer didn't exist? (SABs aren't polyfillable but suppose they were) [11:06:12.0000] then i'd be able to stick it on ArrayBuffer [11:06:22.0000] as opposed to having to make a new global, which might conflict with any existing global, etc [11:06:27.0000] right, but what if you also needed to make the new global? [11:06:33.0000] then i'm no worse off [11:06:39.0000] (than with SAB) [11:06:48.0000] is this rgn talking? [11:06:49.0000] i agree it's a minimal difference ofc, which is why it's very secondary to "organizational" [11:07:02.0000] Bakkot: it's rick button [11:07:06.0000] Bakkot: not sure the acronym [11:07:10.0000] rbu [11:07:10.0000] sorry, thanks [11:07:17.0000] ljharb: i was thinking it's worse off than existing because for 2 different globals, their polyfills would compose naturally and just work [11:07:21.0000] ljharb: but if they're nested, there's more coordination [11:09:23.0000] i have to stop notes [11:09:30.0000] poo ^ [11:09:33.0000] shu: i think it's the same that way [11:11:07.0000] ljharb: okay, i think high order bit for me is i do not want to spend any more time on this [11:11:55.0000] same as yesterday I gotta got AFK the rest of the meeting but will leave the bot running, sorry if it dies [11:14:02.0000] ljharb: i think i'll withdraw my opinion and just ask for Stage 3 with namespaced -- barring possible objections from the other side, of course [11:14:48.0000] shu: i think moddable's claim is stronger than mine; if not for that i'd be willing to go with globals. just ftr. [11:15:12.0000] understood [11:15:36.0000] anybody hearing an intermittent pop on the audio? [11:16:05.0000] when nobody was speaking earlier i was hearing a weird warble, but it's fine when someone is speaking [11:16:24.0000] is this just proposing to shorten {}.hasOwnProperty.call to Object.has? [11:16:33.0000] michaelficarra: yeah, afaict [11:16:51.0000] yes [11:16:54.0000] michaelficarra: it's useful for null-proto things [11:16:58.0000] are we going to do Object.toString next? [11:17:11.0000] if Symbol.toStringTag hadn't made it useless, i'd say maybe :-p [11:17:14.0000] shu: it's not, both of those work on null-proto things [11:17:35.0000] can we get stage 2 on this [11:17:41.0000] it has spec text [11:17:47.0000] michaelficarra: you don't think it's useful to be able to type Object.has vs `{}.hasOwnProperty.call`? [11:17:55.0000] especially with understanding `call` semantics? [11:18:08.0000] shu: not really? they're almost identical [11:18:20.0000] also `Object.prototype.hasOwnProperty.call` versus `{}.hasOwnProperty.call` is a thing [11:18:28.0000] I've found beginners are not comfortable (or don't know how) to do `Object.prototype.hasOwnProperty.call` [11:18:30.0000] this would provide one nice, short, static method [11:18:38.0000] i'm pretty positive on this despite its being an alias, yeh [11:18:39.0000] yeah* [11:18:43.0000] also, hasOwnProperty says "own" in the name, whereas I would assume Object.has had "in" semantics [11:18:54.0000] maybe we can name it hasOwn [11:18:56.0000] yes, i think i would prefer hasOwn vs has [11:19:18.0000] ``` [11:19:18.0000] const uncurryThis = Function.prototype.bind.bind(Function.prototype.call); [11:19:18.0000] const hasOwn = uncurryThis(Object.prototype.hasOwnProperty); [11:19:18.0000] hasOwn({ a: 1 }, "a"); // true [11:19:18.0000] ``` [11:19:23.0000] either has or hasOwn works fine for me [11:19:44.0000] rbuckton: `Function.bind.call(Object.prototype.hasOwnProperty)` is a bit shorter :-p [11:19:46.0000] +1 to the general discussion -- one thing we were also discussing was the proxy has trap, and reflector.hass [11:19:51.0000] rbuckton: but yes, that's exactly what the `has` package does [11:19:59.0000] as potentially confusing bits [11:19:59.0000] Yeah, but I use `uncurryThis` quite a bit :) [11:20:26.0000] rbuckton: https://npmjs.com/call-bind is what all my packages use for that [11:20:47.0000] we will need to educate people on Object.has vs Reflect.has [11:20:58.0000] robpalme: you're assuming anyone knows about Reflect.has [11:21:06.0000] does Reflect.has have `in` semantics? [11:21:10.0000] yes [11:21:11.0000] I think `hasOwn` is my preference, for the same reasoning as ystartsev. `Object.getOwnPropertyDescriptor -> Reflect.getOwnPropertyDescriptor` so `Object.has -> Reflect.has`. Going with `hasOwn` is less confusing. [11:21:24.0000] meanwhile in node https://gc.gy/86647883.png [11:21:45.0000] I agree with @rbuckton, but it's a mild feeling [11:22:08.0000] devsnek: basically the first few lines of every JS program I write [11:22:21.0000]