2021-07-01 2021-07-02 2021-07-03 2021-07-04 2021-07-05 2021-07-06 2021-07-07 2021-07-08 [18:09:04.0013] ljharb: the github pages deploy seems to be broken [18:09:25.0852] seems to be hitting https://github.com/tc39/ecma262/blob/f4694412639e19acab2c0dd5baac247aa7d7a889/scripts/auto-deploy.sh#L6-L7 [07:45:15.0204] is dan clark one matrix? 2021-07-09 [20:02:59.0496] yulia: https://matrix.to/#/@dandclark:matrix.org 2021-07-10 2021-07-11 [12:08:34.0233] Richard Gibson leobalter who's doing the 402 update? [12:10:27.0457] is anyone giving a test262 update? [12:10:59.0122] cc sffc 2021-07-12 [18:26:55.0897] In case anyone wants to figure out when the plenary meeting is in their own time zone (accurately adjusting for DST, of course!), I heard there's a cool ECMAScript API you can use for that. 😀 Just go to https://tc39.es/proposal-temporal/docs/ and open the devtools console in the browser. Just substitute your own time zone and optionally how long after the start of the meeting. ``` Temporal.ZonedDateTime.from('2021-07-13T10:00[Asia/Tokyo]') .withTimeZone('America/Los_Angeles') .add({minutes: 160}) // => 2021-07-12T20:40:00-07:00[America/Los_Angeles] ``` [18:29:30.0256] justingrant can you use `Temporal.now.timeZone()` instead? [18:29:52.0546] Oh, good point! I'll edit. [18:29:58.0101] 😇 [18:31:02.0529] * In case anyone wants to figure out when the plenary meeting is in their own time zone (accurately adjusting for DST, of course!), I heard there's a cool ECMAScript API you can use for that. 😀 Just go to https://tc39.es/proposal-temporal/docs/ and open the devtools console in the browser. Optionally, you can add some time after the start of the meeting. ``` Temporal.ZonedDateTime.from('2021-07-13T10:00[Asia/Tokyo]') .withTimeZone(Temporal.now.timeZone()) // your system time zone .add({minutes: 160}) // => 2021-07-12T20:40:00-07:00[America/Los_Angeles] ``` [08:44:45.0069] ryzokuken is giving the 402 update [11:09:17.0525] iain: hello, [11:09:25.0217] Hello! 2021-07-13 [18:06:26.0560] tcq is back! 🥳 [18:10:05.0201] Yes sorry about TCQ friends. Freak accident combined with paternity leave was a bad combo :-P [18:12:14.0011] Can an admin update the Reflector link in the room description? [18:12:14.0620] https://github.com/tc39/Reflector/issues/380 [18:12:49.0901] bterlson: Congrats on paternity! [18:20:47.0713] Does anyone know what the current status of archival is, in terms of whether we're managing to archive everything in our GitHub org, and how to access the archives? [18:34:31.0785] why are there multiple JSON standards? I thought ECMA-404 was the "canonical" JSON standard but apparently IETF has its own JSON? [18:35:24.0592] everyone considers their own standard canonical! [18:35:59.0357] well, let me rephrase, I thought JSON was TC39's domain... [18:36:04.0855] https://datatracker.ietf.org/doc/html/rfc8259 btw [18:36:15.0574] a musical canon of standards / a round of JSON? [18:36:42.0852] * a musical canon of standards / a round of JSON? [18:37:29.0282] I see them as complimentary standards. ECMA402 is very conservative, describes syntax mechanically, doesn't add much editorial fluff or advisory information [18:37:33.0036] wonder if there's any difference between the two standards: if the IETF standard is a subset/profile then I guess that's not _that_ unexpected. [18:37:57.0016] I use 8259 when I need to show people why it's a bad idea to use the complete grammar in ECMA-404 [18:38:06.0137] * I see them as complimentary standards. ECMA404 is very conservative, describes syntax mechanically, doesn't add much editorial fluff or advisory information [18:38:16.0203] JSON is cross language/platform :) [18:38:53.0763] e.g. if you expect precision greater than IEEE754 doubles, , you're going to have a bad time, and RFC8259 helpfully calls that out [18:39:49.0187] thanks for pointing out the differences. Is something on that published somewhere? (maybe you should write something, it'll be useful 🙈) [18:40:33.0034] but I generally expected the IETF standard to be more... concise. This is definitely a fun data point! [18:43:37.0212] the next IETF meeting (november 2021) is supposed to be in-person... [18:43:44.0653] You can ctrl+f rfc8259 for the phrase "interoperable in the sense that" to see the places where IETF suggested you avoid some corner of JSON [18:43:46.0187] https://datatracker.ietf.org/doc/html/rfc8259#section-1.2 includes explicit reconciliation: > The reference to ECMA-404 in the previous sentence is normative, not with the usual meaning that implementors need to consult it in order to understand this document, but to emphasize that there are no inconsistencies in the definition of the term "JSON text" in any of its specifications... If there is a difference found between them, ECMA and the IETF will work together to update both documents. [18:43:52.0802] Yeah, JSON itself do not support specific type, there is always confusion/complain about int64 [18:44:39.0796] > <@bterlson:matrix.org> You can ctrl+f rfc8259 for the phrase "interoperable in the sense that" to see the places where IETF suggested you avoid some corner of JSON neat, thanks! [18:44:52.0424] We also have the trouble of serialization of BigInt/Date/etc. [18:45:26.0113] HE Shi-Jun: what's wrong with ISO8601/RFC3339 for Date serialization? [18:45:49.0443] One problem we run in to is you need to know schema to know whether to treat a string value as a date value [18:46:09.0198] The problem is you don't know whether it's a date value or string :playful: [18:46:18.0339] implementations which detect date-like strings and convert to date types have been highly problematic in the past [18:47:24.0772] int64 has similar problems - there is no good option. You encode as a number literal and lose precision as the json document traverses a JS runtime. Or you encode as a string and you either need schema or users have to deal with converting to int64 themselves. [18:47:37.0041] * int64 has similar problems - there is no good option. You encode as a number literal and lose precision as the json document traverses a JS runtime. Or you encode as a string and you either need schema or users have to deal with converting to int64 themselves. [18:47:41.0042] Previously I wrote a JSON hint proposal ( https://gist.github.com/hax/5691ca8acdf9179e63043857cdc3616b ) to solve the problem in general , does anyone interest in that? [18:47:57.0683] > <@haxjs:matrix.org> Previously I wrote a JSON hint proposal ( https://gist.github.com/hax/5691ca8acdf9179e63043857cdc3616b ) to solve the problem in general , does anyone interest in that? that does sound cool, thanks [18:48:33.0167] well I dunno what's so wrong assuming valid ISO8601 strings were dates? but I might be missing something here [18:48:57.0690] There are many problems 😁 [18:49:12.0895] For example, performance - you are now attempting to parse every string field. [18:49:44.0397] well, I'm running a regex over every field [18:49:47.0258] also, it can become unpredictable what the type of a field actually is - if I so happen to have data that matches the ISO8601 grammar, all of a sudden things are dates, but if not, its strings. [18:49:54.0956] and parsing if it matches the regex [18:50:29.0066] hm, that's fair. I guess you can assume strings and let users deal with things as they want [18:50:43.0951] I think when you know schema, the practice is fine (we do it all the time in Azure), but it gets messy when dealing with schemaless json [18:51:31.0398] sounds fair [18:51:40.0621] You should be able to know _where_ the dates are. Any combing through should be done explicitly by the user if needed... [18:52:35.0642] yeah I think that's right [19:08:17.0093] Leo says he is stepping away and has no update [19:08:33.0711] (for test262) [19:08:58.0113] * Leo says he is stepping away for dinner and has no update [19:16:56.0910] Thank you! I'm back now! [19:20:13.0353] we're going to be hearing from someone from the LF on this topic too, right? [19:20:23.0582] I think so [19:20:33.0195] Rob asked them to present to us and they gladly agreed [19:21:39.0349] Yeah but I don't think we ever got confirmation [19:22:02.0001] hmm, are they not in the call? [19:22:12.0087] Do you know who was going to give the update, so we can try to ping them? [19:22:29.0113] I'm afraid this presentation isn't explaining things very clearly [19:22:29.0970] I think I recall Mike Dolan... [19:23:21.0328] OK, Mike Dolan doesn't seem to be here [19:23:37.0977] does anyone know what acryonym he keeps saying [19:23:42.0694] "GDF"? "TGF"? [19:23:48.0354] JDF [19:23:48.0661] JDF [19:23:59.0567] yeah I don't think anyone from LF ended up making it... maybe we can end this one early and come back to it later? [19:24:00.0199] but I also want to ask what is JDF [19:24:16.0256] JDF https://duckduckgo.com/?q=jdf+foundation [19:24:27.0331] uvenile Diabetes Research Foundation [19:24:28.0699] sorry i didn't mean to drop a ddg link [19:24:30.0484] * Juvenile Diabetes Research Foundation [19:24:33.0426] https://www.jointdevelopment.org/ ? [19:24:34.0380] that was a mistake [19:24:44.0253] yes that ljharb [19:24:55.0346] i just didn't remember their domain [19:26:10.0649] OK, could the chairs figure out who from the LF we can invite to clarify all of these things? [19:26:27.0663] I think Rob was leading this previously, and tried to set up that someone could attend to explain [19:26:59.0097] I think the LF proposal is good, and I'm really confused about why Istvan is casting all this doubt on it. [19:27:05.0782] I'll see if i can get ahold of Mike [19:27:11.0031] yeah [19:27:12.0885] about that [19:27:39.0118] anyway fwiw this will be a GA vote, tc39 has very little sway in whether it happens or not [19:27:48.0890] this is too much inside baseball for SDO politics, can we get a champion for either side to explain implications for TC39's working mode? [19:28:04.0673] changes to IPR stuff makes me wary [19:28:41.0140] shu: my understanding is that they do not want to change the IPR, on the contrary, they want to be able to veto changes to the IPR policy [19:28:55.0059] that is a change to the process [19:29:07.0252] (because they value the status quo) [19:29:09.0486] that veto power is a special power given to LF over other members [19:29:11.0329] the idea is just to make sure that we keep the IPR policy open [19:29:14.0680] i do not understand that change [19:29:48.0594] I think the LF partnership would be very valuable, and we should discuss it further with them. I am not sure if Istvan is the best person to explain this to TC39. [19:29:51.0672] > <@shuyuguo:matrix.org> that veto power is a special power given to LF over other members It is. I proposed allowing all members to be able to veto that, since it's so central to how we work... [19:29:53.0550] TC39 is a special snowflake in SDO world, because we work so openly [19:29:58.0624] that is what LF is interested in [19:30:02.0580] our open standards work [19:30:51.0592] > <@dehrenberg:igalia.com> the idea is just to make sure that we keep the IPR policy open that's precisely it [19:31:19.0941] i am not so much concerned with the intentions that are expressed but with the material implications [19:31:38.0835] they want the power to veto future changes that ecma may want to make? [19:31:43.0679] that's my reading [19:32:24.0365] I'll just give my comments here in Matrix [19:32:54.0629] in the exact words, "for decisions that require a supermajority" so mostly just changes to the IPR policy and the bylaws IIUC [19:33:09.0297] this isn't public, as far as I understand - could a mod redact the discussion about it in TDZ? [19:33:34.0260] I really strongly support this partnership. The Linux Foundation can help bring lots of extra interesting work to Ecma, and they can bring technical and administrative support to TC39. We've lacked all of those from Ecma so far. [19:34:05.0113] > <@pchimento:igalia.com> this isn't public, as far as I understand - could a mod redact the discussion about it in TDZ? This channel is all publicly readable [19:34:20.0536] also the logs are public [19:34:26.0198] also I think the agenda is public? [19:35:19.0769] istvan disclosed the topic and his slides on github at least [19:35:28.0596] oh, ok [19:35:48.0298] yeah i don't think it's a secret. there's a difference between "not public" and "private" i guess [19:38:53.0367] I'm not sure that what Waldemar is saying is correct. [19:39:21.0845] anyway the GA doesn't play any role in our actual working mode going towards Stage 4 [19:40:19.0217] under what circumstances would the GA not rubberstamp our standard every year anyways? [19:40:25.0769] yeah, exactly [19:40:53.0102] i still do not understand why they want a veto [19:40:57.0037] I think we should just expect to see a better level of support once the LF is involved, without any real upsets or surprises [19:41:12.0812] they don't want us to turn into every other SDO [19:41:18.0072] shu: my reading is that they want to prevent the ecma GA from making disruptive changes in some scary possible future [19:41:26.0977] shu: The idea was to bring LF people here for this topic. I guess we had some kind of coordination error. Hopefully we can ask them these questions tomorrow. [19:41:31.0664] so join as a voting member, and vote? [19:41:46.0893] like what is the manifest problem in the current process that requires a veto to safeguard? [19:42:09.0269] Isabelle says that about literally every document btw (that they are not final and they are incomplete) [19:42:34.0538] > <@shuyuguo:matrix.org> like what is the manifest problem in the current process that requires a veto to safeguard? I agree with that assessment fwiw. I think a better approach can be worked out. [19:42:53.0570] well, let's hear from LF before drawing a conclusion, they must have had a reason [19:43:05.0091] but that has nothing to do with the engagement in general. These implementation details can be ironed out. [19:45:30.0540] I think Istvan's analysis is unfair and not well-informed. [19:46:39.0535] FYI I did a side-by-side of the video call and the notes document, and it makes jumping in and out of note-taking SO much easier [19:46:54.0270] I highly recommend it for anyone who is note-taking-curious [19:47:24.0021] (it's possible everyone already does this and I am just late to the party) [19:47:31.0181] can someone advance tcq? [19:47:34.0644] littledan's criticism is not helpful here. Istvan is one of the most informed here. [19:47:58.0883] working on it [19:48:25.0697] tcq does not match presentation [19:49:17.0259] yes it does [19:49:38.0838] I'm a bit baffled about how Istvan said he didn't understand the motivation for the partnership, when this was very clearly explained in the GA slides. [19:51:01.0354] This discussion is not very fruitful without someone from LF or Jochen here to correct our misunderstandings. Let's try to get them to attend on a later slot and then return to this? [19:51:04.0774] littledan: No it wasn't. In fact, I've heard a lot of false claims made about the motivation. [19:51:30.0666] Blatantly false. [19:52:01.0762] littledan: to me, the issue is there is a jarring divide between what's said, e.g. "we'll give you more resources, tooling, support, and it'll be great" and what's formally proposed (by-law changes, veto powers), and i'd rather go by what is formally proposed [19:52:33.0867] For Ecma, the LF can bring more work items and technical/organizational services. For the LF, Ecma can give it this additional service (standardization) for its various projects. [19:52:51.0848] (that's the motivation, not the bylaws details, which we'll just have to have LF people here to explain) [19:53:13.0752] I imagine that the LF wants to make sure that Ecma doesn't become closed, that it retains its current openness [19:54:20.0104] maybe missing something obvious: why keep the note about the extends clause? Without designing to extend via subclassing, the fact that an identifier can appear in extends doesn't seem very interesting? [19:56:05.0578] bterlson: i think the "it won't throw" part seems reasonable to call out [19:56:06.0590] What the LF said during the GA is that they're doing this because they wanted an office in Switzerland. [19:56:13.0062] coming from other OO languages, one might think some built-ins are final [19:56:38.0360] Actually nothing is final in ES? [19:56:45.0559] I suppose [19:57:06.0550] if its a living spec that means it can die [19:58:47.0877] As allen explained, this term is used to denote that if you extend it, it keep some invariant. If we remove that, should we add some other text to keep such information? [19:59:22.0633] HE Shi-Jun: we are, we're replacing it in the PR with just "it works with the extends clause" or something to that effect, too lazy to copy out the exact language right now [19:59:38.0895] Great! Thank you! [20:35:57.0532] I don't even see value in that... isn't it true of *every* constructor that it works with `extends`? [20:36:20.0400] no, some specifically don't. [20:37:48.0295] Symbol doesn't, IIUC [20:39:16.0833] hm, I might be wrong, it's not triggering an error but IIRC it's not designed to be subclassable, right? [20:41:57.0083] Richard Gibson: yes, and we will have that text on every constructor [20:42:01.0273] we have a fair bit of boilerplate [20:42:03.0590] seems fine [20:42:24.0565] (to be clear we _currently_ have that text on every constructor, and are not proposing to remove it) [20:45:03.0468] > <@usharma:igalia.com> hm, I might be wrong, it's not triggering an error but IIRC it's not designed to be subclassable, right? `new class extends Symbol {}` does throw tho. [20:46:04.0523] ah, I was just doing `class MySymbol extends Symbol { }` [20:46:12.0717] trying to construct it does fail [20:46:19.0352] `Uncaught TypeError: Symbol is not a constructor` [20:46:50.0494] Does Symbol have the note since it can appear in an extends clause without throwing? 😁 [20:47:23.0899] > may be used as the value of an extends clause of a class definition but a super call to it will cause an exception. [20:47:51.0403] we are nothing if not thorough [20:50:49.0974] I'm just saying I would also support further removal of the "may be used as the value of an `extends` clause of a class definition" text as well. It's not misleading in the same way as the "designed to be subclassable text", it's just of dubious value. [20:51:02.0658] * I'm just saying I would also support further removal of the "may be used as the value of an `extends` clause of a class definition" text as well. It's not misleading in the same way as the "designed to be subclassable" text, it's just of dubious value. [20:56:21.0696] i think it's of value in the places where it makes sense, but the primitive constructors are not those places [21:05:44.0263] how fascinating [21:06:26.0695] non-contiguous weekends, fun [21:06:34.0276] something to add to "falsehoods programmers believe about time" [21:07:49.0035] indeed [21:09:38.0585] can someone put the conclusion in the notes [21:09:43.0150] I couldn't actually follow what the ask was [21:11:01.0809] bakkot: consensus on excluding "search" and "standard" from collations getter [21:11:12.0758] please put in notes [21:18:18.0752] > <@bakkot:matrix.org> please put in notes done [21:46:08.0344] > <@bakkot:matrix.org> something to add to "falsehoods programmers believe about time" https://yourcalendricalfallacyis.com/ [21:52:42.0287] not clear to me that the thing Shane mentions would address Yulia's concern at all [21:53:57.0176] i have trouble understanding the specificity of Yulia's concern [21:55:30.0116] oh i see, iain is explaining, this is helpful [21:56:17.0923] seems to me like the hazard already exists tho, if any browser actually did the thing they're worried about? [21:57:35.0349] yeah, we need a normative PR to ECMA-402 to address the root cause [21:59:53.0875] what's needed is a centralized source-of-truth for these supported values that the different constructors draw from/check against [22:01:31.0165] hello, yes, I'm around to chat about HTML integration if needed. You can find the PR at https://github.com/whatwg/html/pull/5339 [22:05:41.0373] Did I understand correctly that the set of names to be made available in new realms is supposed to be resolved during stage 3? [22:05:52.0849] because that really does not seem like something which is appropriate to stage 3 to me [22:06:17.0175] the set of things that HTML will expose. Each environment can choose its own. [22:07:07.0688] the JS builtins are all available (unless an environment goes and deletes them) [22:07:54.0640] MM has this answer always ready [22:07:58.0900] I love to hear this again [22:08:25.0312] arguably, the HTML folks could be the ones to propose the exact list. We've done some research into possible dividing lines and how they would work out, but we haven't driven to the point of consensus on any particular one yet. [22:09:07.0755] I cannot imagine WHATWG coming up with any answer other than "literally all of them", from my experience with WHATWG [22:09:35.0274] well, that's not where the conversation is with WHATWG right now. I think everyone agrees that, like workers, it is a place where only some of the things should be exposed [22:09:57.0438] so the idea is that WebIDL would have notation like [Exposed=Realm] to opt in to interfaces showing up in realms [22:10:00.0223] i have the opposite intuition, especially with prior art with restricted global scopes like workers as dan says [22:10:10.0218] bakkot I can answer that if you bring it to the queue, but it's hard for me to multitask right now [22:10:16.0044] * bakkot: I can answer that if you bring it to the queue, but it's hard for me to multitask right now [22:10:24.0194] ugh sorry I've been trying to take notes [22:10:27.0988] The specification on the JS side imposes restrictions on the capabilities that globals in realms can expose [22:10:32.0827] POO: more note takers [22:10:38.0430] can someone TCQ that [22:12:27.0032] > <@shuyuguo:matrix.org> i have the opposite intuition, especially with prior art with restricted global scopes like workers as dan says that's reasonable. so I guess not all of them, but rather "all but an explicitly omitted subset" [22:15:34.0995] what's the phrase jack is saying? [22:15:40.0537] i heard "hyper graph membrane"? [22:16:00.0607] bakkot: one thing from the ES draft: the realms API require the globalThis to be an ordinary object and all the properties must be configurable [22:16:14.0693] i'm still really salty about not even having opt in object sharing [22:17:22.0194] i... cannot follow this conversation [22:19:09.0336] it's a very complicated realm (sorry sorry sorry) [22:20:17.0512] i don't know where the queue is [22:20:33.0352] the queue is up-to-date [22:20:37.0550] tcq link is in the reflector (https://github.com/tc39/Reflector/issues/380) [22:20:44.0681] * it's in the reflector (https://github.com/tc39/Reflector/issues/380) [22:20:47.0208] i mean on tcq [22:20:52.0970] * tcq link is in the reflector (https://github.com/tc39/Reflector/issues/380) [22:20:55.0322] jack works is speaking rn? [22:21:39.0416] yea sorry for the confusion, i already had tcq open [22:21:42.0915] yeah but they skipped their own item 😅 [22:21:47.0405] was just trying to figure out who was speaking [22:23:59.0755] > <@shuyuguo:matrix.org> i heard "hyper graph membrane"? yes [22:25:43.0101] thanks [22:26:34.0682] > <@ljharb:matrix.org> it's a very complicated realm (sorry sorry sorry) 😂 yeah, a complicated kind of membrane, but it is useful when doing permission controls [22:27:00.0191] it's a bit like what Firefox implemented in web extension (X-Ray vision to C++ objects) [22:27:22.0792] Jack Works: apologies, i was making a pun about the topic of membranes/realms being complicated :-) should have done it in TDZ [22:27:38.0072] * Jack Works: apologies, i was making a pun about the overarching topic of membranes/realms being complicated :-) should have done it in TDZ [22:35:07.0382] As Mark said, "The callable boundary meets the use cases that most of us have in mind"--This is what I was trying to get at. It's iterating to meet the previously articulated goals. [22:35:34.0929] "most of us" may apply to the champion group, but does not necessarily apply to the entire committee, nor to the users who have been hoping for Realms for half a decade [22:35:43.0422] * "most of us" may apply to the champion group, but does not necessarily apply to the entire committee, nor to the users who have been hoping for (object-sharing) Realms for half a decade [22:35:50.0832] (sorry for interrupting; Leo is making a good point) [22:38:38.0193] it looks like different targets are conflicting [22:39:18.0322] virtualization wants clean realm, security wants absolute boundary [22:39:44.0895] I don't see a conflict, they're just different feature requests [22:39:55.0073] and other cases want direct object sharing and vendor-modified realm [22:40:20.0408] This Realms proposal does not make the Node.js vm module obsolete. That doesn't make it unmotivated. [22:40:53.0569] yeah but vm module only available on Node [22:41:19.0766] using iframe is awkward cause there are unremovable things like location [22:43:04.0704] agree with dan here, the shape of the counterargument from jordan and gus seems to be, "the old proposal solved what i wanted to do as well, and this new proposal reduced the scope, so i'd rather this not move forward because it'd preclude what i want with direct object access" [22:43:14.0098] i cannot understand how someone could block having an option [22:43:29.0000] but this proposal moving forward doesn't remove the objection with direct object access [22:43:35.0359] like what concern drives that [22:43:38.0925] devsnek: mark explained it [22:44:02.0328] mark explained why `unsafeObjectSharing` option is bad? i must've missed it [22:44:46.0176] +1, I've proposed to give developers choices but not accepted by the champion [22:44:49.0623] that the value for building in an isolation into the platform as a safeguard against a footgun is that it's not escapable [22:45:06.0789] escapable by who [22:45:11.0226] if you make it escapable, we shouldn't really take the time and effort to build the isolation into the platform [22:45:13.0358] by the developer [22:45:17.0963] Making a new Realm is just a very bad way to get a fresh copy of built-in functions. It's not going to be very easy to optimize to make way too many Realms, and it will create things in the wrong Realm. [22:45:19.0282] is the developer gpt3? [22:45:26.0512] what? [22:45:29.0647] We can made isolation _by default_ but leave a escape path [22:45:32.0962] who is accidentally typing out `allowUnsafeObjects: true` in their code [22:45:38.0921] not accidentally [22:45:51.0484] consciously choosing it without understanding the consequences [22:46:02.0298] or being overconfident in their userland isolation library [22:46:06.0562] Sorry, is arguing points in writing not sufficiently open? Didn't we have a big thread about this all? [22:46:32.0497] that seems pretty condescending :/ [22:46:42.0113] littledan it may have been [22:46:45.0093] sorry, something i said is condescending? [22:46:59.0374] > <@dehrenberg:igalia.com> Sorry, is arguing points in writing not sufficiently open? Didn't we have a big thread about this all? actually I think all things we discussed here is discussed in the thread, there isn't really new things 😂 [22:47:07.0503] As Greg is next in the queue: `Greg Whitworth (GCW)` (cc bakkot ) [22:47:19.0876] assuming that developers can't make informed decisions and tc39 needs to hold their hand through using realms "safely" [22:47:54.0968] * assuming that developers can't make informed decisions and tc39 needs to hold their hand through using realms "safely" [22:47:59.0807] what about malicious developers running scripts on a secure platform though? [22:48:01.0655] it's not pure assumption, this was informed by enthusiasm from some Google internal folks as well as others on Twitter who were excited to use the previous Realm proposal to run untrusted code [22:48:06.0557] or running untrusted scripts? [22:48:10.0962] thinking it was a lightweight sandbox [22:48:49.0982] if you leave the "thisBreaksTheSandboxAllowObjects" option unspecified it apparently is a lightweight sandbox [22:49:07.0210] i would be fine with the option being called that [22:49:47.0108] anyone I'm natural on the isolated version, the things I worried about is how to pass ArrayBuffer [22:49:59.0746] > <@usharma:igalia.com> what about malicious developers running scripts on a secure platform though? if the malicious person is outside the realm what does any of this matter anyway [22:53:10.0918] (A random footgun.png) [22:53:16.0695] the malicious code is inside but direct object access allows them to access globals from the outside [22:53:40.0158] don't enable the option for malicious code [22:56:02.0339] bakkot: ping [22:56:28.0951] sorry, another 500 [22:56:32.0752] restarted [22:56:46.0302] it's back!! [22:56:47.0725] thanks! [22:56:55.0852] I didn't have TCQ open, sorry I jumped right in [22:57:00.0764] given the really short schedule, maybe we can have an overflow item (of an hour or two?) [22:57:13.0555] > <@joshbdev:matrix.org> I didn't have TCQ open, sorry I jumped right in that's OK, notetakers have priority [22:57:30.0700] (it's actually the google docs API which is 500'ing, not as I previously claimed the google speech API) [22:58:02.0404] > <@dehrenberg:igalia.com> given the really short schedule, maybe we can have an overflow item (of an hour or two?) I'll ask at the end if folks are okay with that [22:59:22.0229] Because this is a very complicated topic, could we have a summary about the argument if we decide to continute the topic tommorow? [23:05:58.0729] HE Shi-Jun: this is related to the slide 6 https://docs.google.com/presentation/d/1MgrUnQH25gDVosKnH10n9n9msvrLkdaHI0taQgOWRcs/edit#slide=id.ge435a9058a_0_563 but I'd leave the summarization open [23:11:31.0173] Thank you. [06:06:29.0156] It looks like the sign-in form on the meeting logistics issue is pointing to the May meeting https://github.com/tc39/Reflector/issues/380 [06:07:08.0455] Does anyone have the actual link to join the meeting? [06:42:01.0454] It's the same as the one that form gives you 2021-07-14 [17:47:18.0551] I am having more trouble than I expected being awake for TC39, so I will skip the first half of the day, and be present in the second half. Thanks for understanding. [17:59:59.0077] ljharb: my computer started freezing as soon as you started addressing me so I have absolutely no idea what you said [18:00:21.0085] bakkot: ah np, was just casually mentioning that https://github.com/tc39/ecma262/pull/2125 is ready to go once you and/or shu have signed off on it :-) [18:00:29.0224] gotcha, thanks [18:02:01.0048] my presentation: https://github.com/tc39/proposal-private-fields-in-in/issues/7 [18:02:19.0598] imagine, `__proto__` outside of annex b [18:02:43.0697] haha dang, jmdyck said he wants to stop thinking about this [18:02:57.0684] he is usually indefatigable [18:12:34.0127] for the notes, who is speaking? [18:12:42.0846] Dan Clark? [18:12:52.0981] bakkot: DDC [18:13:50.0629] ryzokuken: I just want to confirm - and inform - the Realms champions will be available tomorrow for the overflow time, but some people won't be available tonight [18:14:30.0715] oh that's helpful info [18:14:40.0794] leobalter: i was just about to attempt to squeeze it in later today [18:15:15.0080] Thanks, Aki ! By the end of the meeting yesterday we said Wednesday and Caridy won't be able to attend today/tonight [18:15:17.0130] leobalter: thanks for letting us know! [18:15:39.0243] and by Wednesday we mean the 3rd day of the meetings [18:15:46.0843] w/th [18:16:10.0699] leobalter: after lunch, right? [18:17:13.0168] Let me confirm with Caridy, because I'm guessing the first time available would be doable [18:17:47.0149] okay. i just had y'all's scheduling constraints [18:19:50.0415] Aki: Caridy is available after 11PM East Time (3rd day)... this should be the lunch time [18:31:43.0329] FWIW I agree with @shu [18:31:54.0860] damn it [18:31:55.0686] I'm still not used to the autocomplete [18:32:07.0479] what is the host hook on this slide for? [18:32:08.0099] I think allowing some JavaScript assertion is important [18:33:34.0424] I got this book at a thrift store when I was a kid [18:33:42.0255] this was in like 2009 or something [18:33:51.0208] JScript always stuck in my head after that [18:34:17.0590] ohno [18:36:18.0082] decorators? in *my* javascript? [18:37:22.0185] 💩 queue advance? [18:38:55.0163] queue advanced, thanks and sorry [18:53:28.0011] the example code is leaking privates... [18:53:57.0633] intentionally, sure [18:54:28.0516] no, i mean it's only want to leak to test, but actually someone can get it [18:55:10.0502] i think he means, now everything that is not the test can use it too [18:55:28.0110] but that's because they stored it on metadata [18:55:36.0672] true, because symbols are public [18:55:43.0054] if you stored it somewhere else, like in the test library, it wouldn't be leaked [18:55:48.0849] So it's a bat example... [18:55:52.0308] bad example [18:55:58.0400] 🤷‍♀️ [18:59:28.0552] devsnek: So we should fix the example to store it in somewhere else, or people may just copy the example code in the proposal repo :) [19:02:00.0809] I remember rbuckton have a similar proposal (but different syntax) for auto accessor? [19:04:32.0025] We are a bit faster compared to the initial schedule, I believe it's good if we want to extend time to clear out questions about Decorators [19:04:58.0025] as in, saving from time when it's eventually presented for Stage 3 [19:05:39.0249] ljharb: you can just have a different private field that you check, surely? [19:05:55.0061] objects can be partially populated with fields. [19:06:00.0002] meh [19:06:03.0995] technically true, not super relevant [19:06:04.0379] lol [19:06:14.0467] just put the field next to the accessor, now both must exist or neither do [19:06:18.0228] there's also value in being able to be explicit instead of dancing around what i'm trying to check [19:06:28.0868] sorry, for the notes, who just talked? [19:06:48.0748] bakkot: seems not a good code style :) [19:07:06.0730] eh, checking in general seems like not good code style [19:07:12.0780] sounds like a good ESLint contribution :P [19:07:19.0499] just do the thing and if people misuse your class they get an error, it's fine [19:07:44.0132] static methods should check [19:07:46.0334] but not `this` [19:07:51.0771] lol that is a subjective debate that probably isn't productive to have, but suffice to say that is not a universal api design principle in userland [19:07:52.0472] so if auto accessor i think we should use class brand check (class.hasInstance proposal) [19:08:19.0828] **for the notes, who just talked**? [19:08:27.0790] ah, rgn, thanks whoever put that in [19:08:34.0674] richard gibson, I was looking [19:11:57.0971] -2 points for not using .js.org [19:12:30.0932] it would be nice if that was in a more neutral home [19:12:37.0880] (js.org) [19:14:50.0488] shu: when you take the questions back, please make sure to ask about interleaved vs. at-the-end initializers [19:15:20.0338] Richard Gibson: specifically, if we would have concerns with making `addInitializer` unconditionally available if they were all at the end? [19:15:34.0842] correct [19:15:43.0740] roger [19:15:50.0255] that feels okay to me [19:16:15.0243] it may not fly for other reasons, but I am still interested in the answer [19:16:23.0243] i can't speak to if the use cases `@init` is supposed to solve still work fine with all-at-the-end [19:16:29.0295] but impl wise seems fine [19:16:40.0394] right, exactly [19:16:54.0303] my `@bound` use cases do require it be interleaved [19:16:57.0185] initializers at the end feels weird in the case of multiple decorators [19:17:08.0086] so that number 2 can store a bound reference to number 1, eg [19:18:51.0616] Justin Ridgewell: this actually identical to the find/findLast precedent [19:21:33.0860] @ljhar [19:21:47.0623] * @ljharb: how would that break down with at-the-end evaluation? [19:21:55.0635] bterlson: Aki could you give the delegate role to dcrousso ? [19:22:14.0982] or rather, at-the-beginning so it can be accessed _in_ the constructor [19:24:08.0726] someone needs to be muted [19:24:10.0670] Richard Gibson: `class C { @init:bound x() {} foo = this.x; }` - now, on a `const i = new C()`, `i.foo` is an unbound `x` if not interleaved [19:25:08.0112] ack, thanks [19:25:18.0681] "any objections?" _almost silence but background noise that sounds like hammering_ [19:25:35.0168] ok to interrupt and ask if the mic gain can be turned down? [19:25:37.0073] * "any objections?" _almost silence but background noise that sounds like hammering_ [19:25:38.0861] ow my ears [19:25:54.0436] is philip making popcorn [19:26:32.0253] so much better, thanks [19:26:54.0813] `setTimeout` with a capital T [19:27:10.0443]