2023-04-01 [19:11:30.0014] https://web.archive.org/web/20160328225427/wiki.ecmascript.org/doku.php?id=strawman:catch_guards [19:12:25.0549] If non match, it rethrows [19:12:31.0467] * If none match, it rethrows [23:11:52.0670] i can't imagine it working any other way [09:52:27.0609] “Rethrows” sometimes could act differently from “doesn’t catch” with respect to things like dev tools (with the latter being more useful). This is actually a potential advantage of a built in catch guard construct, but could also add significant implementation complexity [09:53:25.0478] (The complexity comes when you need to evaluate JS to determine whether the guard hits, but then go back and “don’t catch” as if that didn’t happen) [13:40:36.0449] oh true, good point. in that case i'd expect it to mean "doesn't catch", but the desugaring would be basically rethrowing [13:40:57.0827] to runtime JS i don't think there'd be a difference, only to dev tools/engines? [13:45:19.0002] Right 2023-04-04 [04:18:53.0999] What does `MV` stand for in https://tc39.es/ecma262/#sec-string-literals-static-semantics-mv? _M-escape Value_? [04:18:59.0464] * What does `MV` stand for in https://tc39.es/ecma262/#sec-string-literals-static-semantics-mv? _Mescape Value_? [04:22:19.0059] I think mathematical value? It's computing the escape code point number [04:38:46.0701] Ohh it makes sense, probably [05:28:52.0731] The spec used to have phrasing like "are interpreted as having a mathematical value (MV), as described below" until PR #2451 was merged. [05:30:41.0448] maybe it'd be helpful to expand this acronym in an editorial PR? [05:30:47.0170] (^ good first PR?) [05:34:36.0485] Do you mean add a sentence that gives the expansion, or change the SDO name to something longer? [05:35:19.0489] change the SDO name to something longer [05:35:46.0367] (more sentences of explanation are good too but I was suggesting the latter) [05:47:40.0679] One wrinkle is that if you simply expand "MV" to "MathematicalValue", then you have 2 terms ("MathematicalValue" and "mathematical value") which denote distinct ideas, but only differ by capitalization+spacing, which is probably not good. (Which was sort of the point of #2451, but from a different angle.) [05:48:30.0081] So if we did rename the SDO, an appropriate name might be something like NumericLiteralValue. [05:54:10.0956] Similarly, SV -> StringLiteralValue, TV -> TemplateLiteralValue, TRV -> TemplateLiteralRawValue ? I don't know, I think I prefer the current names. [05:55:43.0111] But I agree that some kind of clarification would be good. 2023-04-07 [13:34:48.0262] Anyone have a pointer to some place where "bindings in `if()` heads" was discussed in the past? [13:39:16.0568] that would've been during ES6 when `let` was being decided on... not sure where/whether that's reflected in the notes. I'd ask dherman [13:43:09.0871] there was a proposal for it later [13:43:13.0975] keith miller has wanted to add that in the past [13:43:26.0287] yes, that must be what i'm thinking of [13:43:52.0317] https://github.com/tc39/proposal-Declarations-in-Conditionals [13:43:59.0506] https://github.com/tc39/notes/blob/HEAD/meetings/2019-10/october-2.md#declarations-in-conditionals [13:58:00.0442] It's been 2 weeks since the TC39 meeting; time for notes to be published? [14:01:55.0602] > <@jmdyck:matrix.org> It's been 2 weeks since the TC39 meeting; time for notes to be published? today is the day [14:14:21.0376] bakkot: Ah, thanks! 2023-04-08 [01:50:44.0832] https://github.com/tc39/notes/pull/241 - one day delayed (I was visiting family yesterday and got back later than planned) 2023-04-09 [16:19:31.0363] Boa noite [16:20:01.0342] Você: Alguém poderia me ajudar? Você: Invadiram minhas contas de Gmail e Hotmail e trocaram a senha e telefone de login 😔 Você: Posso comprovar minha identidade [16:22:11.0784] Could someone help me? They broke into my Gmail and Hotmail accounts and changed the password and login phone 😔 I can prove my identity 2023-04-10 [19:06:13.0623] Can someone help me there, guys? [19:33:05.0640] I doubt anyone here can help you. 2023-04-11 [07:18:25.0117] In the TC39 Tools outreach call, we're looking into improvements to source maps. Maybe they should eventually be standardized in TC39? We're discussing this in #source-maps:matrix.org and collaborating in GItHub, e.g., some initial shared goals are at https://github.com/source-map/source-map-rfc/issues/22 . Please join us if you're interested! [13:16:03.0391] Can't TC39 only work on Ecma documents? Are you suggesting that Ecma should adopt the source map spec? [13:18:12.0581] Yes [13:18:35.0886] This is the question I would like input on: Should TC39 and therefore obviously Ecma take on this sort of work? [13:20:14.0151] I think TC39 is a good place because we assemble a lot of relevant stakeholders, and because we have good IPR protections. But if the committee says no, there are lots of other possible paths. [13:20:39.0385] I imagine source maps would be a separate document though [13:41:55.0579] I tend to see the formal standards process as something to be adopted only as a last resort if necessary to allow companies to coordinate on tasks that might have IP or antitrust implications. If the potential contributors / users of a spec are able to cooperate without needing the aegis of an actual standards body that's going to be better. [13:42:30.0333] For source maps, is there a concern about IP/antitrust? [13:48:10.0339] there are always concerns about IP/antitrust [13:48:33.0020] I think it is reasonable to be concerned about IP for all sorts of technical artifacts like this. (I have no understanding of what antitrust is supposed to mean in a standards universe where WHATWG is apparently kosher.) The community shares an interest in having a solid written description, test cases, and process for continuing changes. I think TC39, or likely a TG4 of it, would provide a good context for this. If TC39 says no, I would encourage the community to start in WICG and then figuring out details later. [13:49:26.0600] and _not_ having it under the auspices of a standards body can make it difficult or impossible for employees of large companies to contribute [13:50:12.0527] It is a common pattern in the web world to initially not bother with standards and then realize they are essential, see console, WebDriver, WebExtensions, … [13:51:40.0153] We live in a world of social constructs where the perceived legitimacy of a standards context acts as a culturally defined glue that encourages everyone to cooperate. TC39 can decide whether to invest its legitimacy in this project. [15:24:22.0819] who currently owns the IP for the source maps spec? Mozilla? [15:24:28.0975] they would have to assign it to Ecma, right? [15:28:31.0568] License, not assign [15:28:54.0530] sure [15:28:57.0695] but is it Mozilla? [15:29:05.0958] This is an advantage of working within an established standards organization that everyone who owns the relevant IP is already part of [15:29:24.0899] I think Google would have more of a claim to the current version but I would need to check [15:31:03.0642] does Ecma have experience adopting existing works with mixed provenance? I would assume so [15:31:27.0069] Well… JS is one of those things [15:32:06.0046] But apart from that, if the IP is owned by member companies, the act of standardizing it will cause the licenses to trigger [15:35:10.0924] So far, I haven’t seen Ecma support TC39 with IPR infrastructure the way the W3C has. They sort of defer to us there. So I don’t think we will find pushback on the Ecma side, but I can float this at the upcoming ExeCom meeting to ferret out concerns if you think that it’s a good idea (arguably that would be out of order though; I was planning to raise it to committee first) [16:03:49.0536] I think it's pretty appropriate for TC39 to adopt it, considering the cross-cutting concerns [16:04:06.0414] so I personally would support it [16:04:20.0225] It is important that source maps stay multilingual, but they are likely to grow some more JS-specific features [16:04:37.0903] or at least make design decisions informed by JS, for sure [16:05:25.0271] yes, we have an interest in ensuring that they remain a good fit for JS and JS developers' needs [16:05:39.0521] Some parts may have web tie-ins too, e.g., one of the problems with source maps is that it's ambiguous how the url is interpreted. 2023-04-12 [07:22:50.0964] does anyone know of npm packages / libraries that depend on the non-standard `.stack`? [07:31:12.0573] > <@shuyuguo:matrix.org> does anyone know of npm packages / libraries that depend on the non-standard `.stack`? https://www.npmjs.com/package/get-caller-file [07:33:16.0172] It also depends on v8 specific Error APIs [07:33:35.0228] Babel does some stack trace manipulation to show both plugin files and the code that originally called Babel [07:35:24.0834] (It also uses prepareStackTrace) [07:37:15.0861] thanks luca and nicolo [07:37:32.0659] the context here is we're going to make it an accessor property instead of a data property because that's the right thing to do [07:37:45.0200] hopefully we don't break too anything but now i need to read these packages [07:38:40.0740] (we not only use `.stack`, but also do very bad things like relying on `.prepareStackTrace`) [07:38:52.0216] > <@shuyuguo:matrix.org> the context here is we're going to make it an accessor property instead of a data property because that's the right thing to do It won't break Babel [07:38:56.0662] Some of our enterprise customers also make use of Error.stack in various ways [07:39:51.0471] > <@nicolo-ribaudo:matrix.org> It won't break Babel Oh actually, we do reassign `.stack`, so if it's only a getter it might throw on assignment [07:40:09.0110] I’ll check with our customers whether this will break them [07:41:11.0437] so, currently it's not a _real_ data property. it appears as one but it as C++ getter and setter [07:41:19.0918] we want to change it to an accessor property, it'll have the same getter and setter [07:41:25.0845] assignment should still work [07:41:36.0788] what'll break is stuff like `getOwnPropertyDescriptor` and depending on its being a data property [07:41:44.0129] > <@lucacasonato:matrix.org> I’ll check with our customers whether this will break them thanks! [07:41:58.0266] * so, currently it's not a _real_ data property. it appears as one but it has C++ getter and setter [07:42:18.0495] I like this change. I'll note that I previously changed some random Intl/Promise stuff into getters/setters when trying to deprecate them, and it didn't seem to break anything. But each case is random and different. [07:42:47.0811] yeah [08:50:34.0784] that's amazing, thank you - it will dramatically reduce the web reality that the stack proposal has to account for [09:02:22.0255] fingers crossed on no breakages [09:16:33.0084] > <@shuyuguo:matrix.org> thanks! Yeah, no breakages for the customer I was concerned about. 👍 from me [11:12:27.0330] thank you for checking 2023-04-14 [01:28:23.0974] Is anyone still researching base64 utilities? [02:06:24.0391] bakkot updated the base64 proposal just last week. https://tc39.es/proposal-arraybuffer-base64/ [03:25:24.0780] Thanks, it seems that has the relevant issues that need to be solved as well [03:26:02.0942] I'm getting closer to understanding (and improving) how WebKit handles all of this which should help eventually driving those to some resolution [08:45:09.0274] I am hoping to bring it for stage 2 next meting [08:45:18.0881] * I am hoping to bring it for stage 2 next meeting [08:46:10.0524] currently leaning towards, the decoder will be lenient in accepting whitespace / not enforcing `=` padding, and the encoder will be strict in not producing whitespace and always producing `=` padding [08:46:23.0019] and then maybe not having options for those, unless there's a compelling case made [08:46:45.0504] I was originally planning on having options for how to handle whitespace and `=` but they're probably not actually necessary [09:51:14.0622] bakkot: what I'm learning in WebKit thus far is that the options differ between base64/base64url [09:51:34.0125] fascinating [09:51:56.0610] bakkot: only base64 has a lenient decode mode of sorts compatible with atob/data: URLs [09:52:29.0727] also, some places (possibly including the CSP spec?) allow "mixed" decoding, where you can just mix characters from either alphabet, which I am not current planning to support because, gross [09:52:39.0804] Which also kinda matches what I've seen in standards, though I haven't tested base64url endpoints myself [09:53:04.0811] I thought CSP relied on comparing the result of encode from our past discussion, but also have never attempted to test myself [09:53:40.0555] that is correct but it does a find-replace first [09:53:59.0916] https://www.w3.org/TR/CSP3/#match-element-to-source-list step 5.2.5.2 [09:54:26.0498] so in practice it is equivalent to doing a strict decoding but with mixed alphabet [09:54:33.0756] * so in practice it is equivalent to doing a strict decoding (i.e. enforcing padding) but with mixed alphabet [09:54:55.0411] I would also be 0% surprised to find that implementations differ from the spec on that point [09:57:02.0657] ok actually I have reminded myself that it's more complicated because the SRI check, unlike the hash-source check, does not include the find/replace step https://github.com/w3c/webappsec-csp/issues/423 [09:57:12.0917] again this is just the spec, no idea what implementations do [10:02:12.0185] Yeah, CSP is pretty bad on a number of fronts so maybe not the best place to draw from. Though if you're inclined to sort it out a bit I'd be happy to help [10:03:11.0189] I did open a few PRs a couple years back and they got no attention, so I stopped doing that [10:03:34.0204] I guess they're conflicting now so clearly someone has done at least some work [10:20:52.0396] That's unfortunate [10:21:12.0113] There has been some more maintenance as of late, but nothing spectacular [10:25:53.0461] Yeah probably worth trying again [10:26:07.0987] There's a lot of specs which could use some love [11:40:51.0206] Has there been a proposal to support HTTP headers with the (dynamic) module import syntax? [11:54:36.0653] It would be useful to pass an `Authorization` header than being forced to pass a token as query param (easily vulnerable). [13:13:37.0984] * It would be useful to pass an `Authorization` header than being forced to pass a token in the URL (easily vulnerable). [13:13:55.0227] * It would be useful to pass an `Authorization` header than a token in the URL (easily vulnerable). [13:27:51.0534] https://tc39.es/ecma262/#sec-LoadRequestedModules [13:28:22.0899] > `import()` expressions never set the `hostDefined` parameter [13:30:28.0614] https://github.com/tc39/proposal-dynamic-import/issues/76 [13:32:50.0323] https://github.com/tc39/proposal-dynamic-import/issues/84#issuecomment-855285508 there's what appears to be a workaround here, but I didn't scrutinize it [13:49:44.0030] https://github.com/tc39/proposal-import-attributes [13:50:25.0086] this proposal could conceivably support it, but handling the options is the domain of the browser/runtime [14:49:44.0187] Thanks Chris de Almeida [14:50:35.0291] happy to help [14:54:02.0748] > <@softwarechris:matrix.org> happy to help Would the Blob method allow relative imports from the module? [14:55:39.0583] what do you mean? [14:59:35.0042] The module would be perceived as from the Blob URL, so any ``` import('../somefile.js') ``` would break if called from the imported module? Think I've tried a similar method (`import( * The module would be perceived as from the Blob URL, so any ``` import('../somefile.js') ``` would break if called from the imported module? Think I've tried a similar method (`import( * The module would be perceived as from the Blob URL, so any ``` import('../somefile.js') ``` would break if called from the imported module? [15:02:35.0937] * The module would be perceived as from the Blob URL, so a ``` import('../somefile.js') ``` would break if called from the imported module? [15:02:51.0996] * The module would be perceived as from the Blob URL, so an ``` import('../somefile.js') ``` would break if called from the imported module? [15:07:59.0879] well, yes. if I understand you correctly that would break but if that's the case, it would be broken without the blob method anyway. it implies you need some sort of build step. the minute you are importing from a url, any relative file imports would be game over [15:10:19.0461] > <@softwarechris:matrix.org> well, yes. if I understand you correctly that would break but if that's the case, it would be broken without the blob method anyway. it implies you need some sort of build step. the minute you are importing from a url, any relative file imports would be game over Didn't quite get it. Relative urls already work on browsers/node? [15:10:24.0217] * well, yes. if I understand you correctly that would break but if that's the case, it would be broken without the blob method anyway. it implies you need some sort of build step. the minute you are importing from a url, any relative (or absolute) file imports from the url-imported module would be game over... edit: probably game over but thinking through this a bit more, I'm not 100% sure because I've never done this.. I would expect it not to work but, where is `somefile.js` ? [15:11:09.0956] > <@softwarechris:matrix.org> well, yes. if I understand you correctly that would break but if that's the case, it would be broken without the blob method anyway. it implies you need some sort of build step. the minute you are importing from a url, any relative (or absolute) file imports from the url-imported module would be game over... > > edit: probably game over but thinking through this a bit more, I'm not 100% sure because I've never done this.. I would expect it not to work but, where is `somefile.js` ? Of course on the server, one level above the absolute URL of the prior module. [15:12:57.0552] `../somefile.js` is not a relative url, it's a relative file path. in any case, at this point, I think I need a more complete example because I'm not sure I'm following you [15:13:56.0321] Sorry. Wrong terming. Let me clarify. [15:16:02.0539] You've got `https://some-server/script/index.js` with a statement ``` import stuff from "./lib/some-util.js"; ``` How does this work with Blobs ? [15:16:28.0735] It wouldn't, whereas it would if you imported directly. [15:29:59.0653] Anyway I've resorted to query parameters for now. [15:31:04.0584] why would credentials in code be less vulnerable than credentials in a query string? [15:31:16.0486] if I understand you correctly, right, that would not work [15:31:33.0139] > <@ljharb:matrix.org> why would credentials in code be less vulnerable than credentials in a query string? Didn't get you. [15:31:36.0512] well -- referrer policy can expose the query string [15:31:56.0218] you said earlier > It would be useful to pass an Authorization header than a token in the URL (easily vulnerable) [15:32:40.0278] presumably the credentials aren't hardcoded... one would hope [15:33:03.0244] > <@softwarechris:matrix.org> presumably the credentials aren't hardcoded... one would hope Idk who hardcodes JWTs [15:33:53.0362] > <@ljharb:matrix.org> you said earlier > > It would be useful to pass an Authorization header than a token in the URL (easily vulnerable) That's the Bearer auth standard, isn't it? [15:34:14.0419] i'm not sure what you mean [15:34:21.0717] where would the credentials come from? [15:35:03.0041] It could come from anywhere? A login? A delegated access token? Does it matter as long the client somehow finds it? [15:35:24.0755] ok so you're not suggesting it live in the source code, you just want a way to tag an import as needing an auth header? [15:35:44.0426] Yeah because not everyone has access to the same scope. [15:36:26.0738] And instead of loading scripts and only blocking data APIs, I've decided to block the whole thing. [15:38:43.0878] I could run you through an example, although the site uses a self-signed certificate at the moment. [15:39:21.0335] * I could run you through an example, although the site uses a self-signed certificate at the moment and I didn't add the whole auth thing yet. 2023-04-15 [00:39:34.0250] bakkot: https://github.com/WebKit/WebKit/pull/12768 [03:30:38.0285] bakkot: per that test failure I discovered my greatest nemesis: SRI [03:31:06.0771] bakkot: it does both base64 and base64url decoding, I'm not sure why they thought this was acceptable 2023-04-17 [22:12:17.0396] Looking at https://tc39.es/proposal-intl-locale-info/#sec-properties-of-intl-locale-prototype-object and trying to figure out why in MDN we have `Intl.Locale.prototype.calendars`, `Intl.Locale.prototype.collations`, `Intl.Locale.prototype.hourCycles`, `Intl.Locale.prototype.numberingSystems`, and `Intl.Locale.prototype.timeZones` — that is, plural — that aren’t in the current spec. Were those in the spec previously but subsequently got dropped? Also `Intl.Locale.prototype.textInfo` and `Intl.Locale.prototype.weekInfo` — similarly, we have them in MDN but they’re not in the current spec. [22:14:15.0662] ah wait, I now see that the current spec has `get*` _methods_ for all those, rather than properties [22:18:30.0773] hmm but I see that Blink has (still exposes) the properties, along with the methods (though WebKit seems to have only the methods) [22:19:56.0326] I’m just trying figure out what to do about it for BCD/MDN — I guess the simplest thing to do for now (and the least work for me…) is to just remove the spec URLs from BCD [12:21:45.0764] sideshowbarker: yes, that changed recently https://github.com/tc39/proposal-intl-locale-info/pull/67 [12:21:52.0793] implementations will probably be updated to match the spec [12:22:04.0513] probably best not to document the old names since that will encourage their use and they will hopefully go away [14:02:11.0317] > <@bakkot:matrix.org> sideshowbarker: yes, that changed recently https://github.com/tc39/proposal-intl-locale-info/pull/67 Aha, thanks for the link [14:07:00.0843] > <@bakkot:matrix.org> probably best not to document the old names since that will encourage their use and they will hopefully go away I think we already have them all documented in MDN, but we'll need to update the articles with banners that say they're deprecated. (Per MDN policy, we don't remove them completely, but instead continue to show what older browsers they were supported in) 2023-04-18 [17:12:36.0244] is there any way to represent an "anywhere on earth" (AoE) time in Temporal, or am I just expected to know what the timezone with the biggest negative offset is at all times? [17:18:23.0622] it would be up to the TZDB to add such a time zone, I guess. if there was a mechanism to find the time zone with the biggest negative offset, it would not work on hosts that ship no TZDB. it would also leak fingerprinting information without obviously doing so [17:18:54.0180] I guess both "everywhere on earth" (highest magnitude negative offset) and "somewhere on earth" (highest magnitude positive offset) are useful, though I have only seen a use for the former [17:19:19.0273] ptomato: it's not a unique timezone, but it could be an alias I guess? [17:31:46.0054] here's an off-the-cuff code snippet that will give you the last possible local time when it is still 2023-04-20 anywhere on earth: ```js const aoeWallTime = Temporal.PlainDateTime.from('2023-04-20T23:59:59.999999999'); const aoeExactTime = Intl.supportedValuesOf('timeZone').reduce((last, id) => { const candidate = aoeWallTime.toZonedDateTime(id); if (!last || Temporal.ZonedDateTime.compare(candidate, last) > 0) return candidate; return last; }, null); const localTime = aoeExactTime.withTimeZone(Temporal.Now.timeZoneId()); console.log(localTime.toString()); ``` [17:39:54.0295] eh, that works well enough for me [17:42:49.0041] might still be nice to be able to actually represent that time in a way that you can pass around to other APIs or store for later [17:45:10.0092] what you store for later depends on whether you want the stored time to change if the host updates its TZDB [17:45:19.0638] I do [17:46:08.0970] if you don't, storing `aoeExactTime.toInstant()` is enough. if you do, you have to store `aoeWallTime` and run this snippet again [17:47:06.0483] yes, exactly, that's the thing I am asking for [17:47:15.0898] it sounds like it will require a timezone alias be added to tzdb [17:48:34.0523] I mean ... this _could_ be a TC39 thing - but that seems like the wrong domain to solve the problem in [04:49:45.0015] Could this be achieved through custom timezones? [04:50:42.0271] Although I guess all the rest of Temporal would need to know how to handle that... We do need an `Etc/AoE` or something of the sort [04:51:10.0708] * Although I guess all the rest of Temporal would need to know how to handle that... We do need an `Etc/AoE` or something of the sort 2023-04-20 [08:52:29.0356] why class field initialization order is all field initializers runs first, then the constructor? [08:53:01.0368] i thought it is more intuitive to run in source text order? [08:54:05.0703] like this: ```js class T extends Q { field = 2 constructor() { 1 super() 3 } field2 = 4 } ``` [08:55:07.0381] spec order is 1-2-4-3 [09:06:14.0590] generally it's more useful to have fields set up before the constructor runs [09:06:38.0183] is there some design principles behind this? [09:06:55.0029] and is it related to decorators? [09:32:27.0135] if it ran in source text order then the `this` it installs field2 on might not be the actual instance, since the constructor could have returned any object [09:33:00.0352] it's pretty important for *private* fields imo, at least, that all of them are installed on the same object, so you can never observe a partially "set up" instance [09:33:33.0317] source text order 1-2-3-4 also installed on the correct `this` value IMO [09:35:37.0663] if line 6.5 did `return {}` which object would get field2? [09:35:50.0843] oh... [09:36:48.0526] ok I understand now 2023-04-25 [10:04:42.0928] Personally interested, but is this appropriate for regular committee time? Should this just be a new TG? [10:21:16.0924] Yeah I think we should make this into a new TG! So it’s on our next TC39 agenda [10:21:51.0357] To discuss whether we are interested in taking this on [11:31:28.0173] https://github.com/tc39/agendas/pull/1361 gentle reminder that the PR for adding sourcemaps to the agenda is still unmerged. waiting on a presenter, it seems [12:36:50.0803] I made this a PR just to trigger notifications for people, not to wait for a presenter; I'll merge it myself [12:38:13.0217] thanks for the reminder, Chris. 2023-04-30 [19:36:48.0493] have any engines implement r&t [19:36:51.0179] * have any engines implemented r&t [19:37:14.0357] i guess its not technically at stage 3 yet [23:51:45.0008] nicolo-ribaudo implemented R&T in SiderMonkey during a Bloomberg internship, and that was continued by Igalia. Was behind a compile time flag. No JIT support afaik. [09:29:15.0250] Tim in Igalia proceeded to implement JIT support. It’s there in a patch in Bugzilla. But it is not expected to land in its current form. [09:29:34.0205] * Tim in Igalia proceeded to implement parts of JIT support. It’s there in a patch in Bugzilla. But it is not expected to land in its current form.