2023-12-02 [09:30:58.0591] Is there a way to view a rendered version of pull requests to ECMA-262, preferably with marked-up deltas? For example, reading a rendered version of https://github.com/tc39/ecma262/pull/2942/files. [09:51:48.0892] jschoi: at the bottom, click "show all checks", then scroll down to "Begin.com build preview ā€” Preview ready!" and click the "details" button [09:52:32.0590] for rendered _diffs_, you can use https://arai-a.github.io/ecma262-compare/ [09:52:51.0651] e.g. https://arai-a.github.io/ecma262-compare/?pr=2942 [09:53:15.0993] Thank you! 2023-12-03 [07:19:09.0594] objection to "tla is not a breaking change" [07:19:17.0689] * objection to "adding tla is not a breaking change" [11:48:18.0778] yeah i find that to be extremely dumb [11:50:21.0405] html should just queue tasks until either the module is done evaluating or until a listener is added [11:50:48.0334] * html should just queue events until either the module is done evaluating or until a listener is added [11:55:21.0011] * html should just queue events until either the module is done evaluating or until a listener is added, or just not support modules as a serviceworker entrypoint 2023-12-04 [02:24:17.0106] "just"... I think SW had module support before TLA. [10:25:48.0975] Disabling TLA in SW was a deliberate restriction; we had a whole discussion about it 2023-12-05 [20:23:28.0118] I still don't understand why service workers can't wait until all modules have fully evaluated to deliver the events. The implementations ought to be capable of detecting when the evaluation won't make further forward progress, and error if the module graph has not been fully evaluated, indicating a top level await is suspended on an event to be delivered, which should be the only violation. [22:51:46.0660] yes they can, but I think that will be a deficit in the user experience (I don't know but I think web requests are blocked until sw initialized) [00:57:57.0302] Indeed, a goal with SWs is that the runtime can be instantiated and discarded quickly. If instantiation needs to be awaited, that would go counter to those goals. https://github.com/w3c/ServiceWorker/issues/1407 has a bunch of the background. [04:45:22.0446] But a top level await does not necessarily mean an actual delay. It could be as short as a microtask for a resolved promise. A typical use case is awaiting a dynamic import, which is arguably equivalent to a static import (besides ahead of time module graph analysis). IMO discouraging bad patterns should not disable part of the language, it could instead be done the same way other bad patterns are discouraged: metrics and perf reports. [04:59:05.0002] SWs make many other compromises of this type 2023-12-08 [09:57:38.0443] FAQ is now public: https://github.com/tc39/faq/ [11:02:22.0519] maybe we should make this part of tc39.es [once its content is more mature], or linked from it 2023-12-09 [21:58:13.0398] A pull request with the word types. Awesome, my kind of discussion. 2023-12-10 [16:05:07.0642] bakkot: I never considered that f() syntax issue. For some reason I thought there was a clever workaround. It can't use context, so a different syntax would need to be used entirely? Not sure if you follow TS stuff, did they talk about that a lot? [16:06:23.0577] I should have figured given Actionscript 3's design and the whole Vector. syntax. [16:56:56.0388] any attempt to actually pull in TS syntax for types would need to choose a different syntax for generic invocation, yes [16:57:38.0339] I wasn't there when TS syntax was originally chosen but I imagine they didn't think it actually mattered given how they intended TS to be used, which was entirely reasonable of them [05:34:19.0074] The more recent conversations in types-as-comments have thought about using "turbo-fish" for passing a type parameter. `new Map::()` 2023-12-11 [09:17:57.0038] Yeah, "writing the comparisons `f < a > ()` is a ridiculous thing to do" is a totally reasonable call for a language that's not JS itself. [09:32:53.0971] `>` is just JavaScript's [abjunction operator](https://en.wikipedia.org/wiki/Material_nonimplication), so it makes perfectly sense to use it with a boolean expression on its lhs :) 2023-12-13 [18:53:52.0624] https://twitter.com/laughinghan/status/1734493133034172478 [19:08:05.0523] mhm, I've gotten presentation mileage out of that [19:30:27.0712] JS's float->int semantics are not x86 behavior [19:31:03.0072] how did someone end up aware of this instruction but still have that confusion [22:16:46.0973] er yeah I didn't even read the tweet but that is a weird misconception 2023-12-14 [10:26:23.0797] Random question. In Chrome devtools "Pause on uncaught exceptions" there's a prediction system involved right? https://jsfiddle.net/qn978wxu/3/ I noticed Firefox correctly handles the second case with Promise.race and knows the promise is caught. Is this a performance thing? I can't seem to find much about it. Simply passing reject into the setTimeout doesn't cause Chrome devtools to break. littledan Did you ever work on something like this? [10:31:52.0835] this doesn't sound like a TC39 question but a Chrome devtools product question. if you notices a difference with other DT where you think Chrome should improve, mind filing an issue? [10:33:19.0076] sirisian: I did work on that but I think that system has been rewritten since then, and also, I was focusing on the syntax-driven parts and sort of assumed that functions like Promise.race were too hard to handle correctly. The system is inherently based on heuristics and a bit incomplete, and will always be possible to improve, so yes, I encourage you to file an issue. [10:34:37.0656] Thank you 2023-12-15 [10:46:46.0422] Uhm, does the spec (+ AnnexB) disallow `-->` as the first line in a script? It seems so (`-->` must be preceded by a line terminator), but all browsers accept `eval("-->")` [10:46:50.0358] (cc jmdyck) [10:47:22.0435] This is the definition of `-->`: https://tc39.es/ecma262/#prod-annexB-SingleLineHTMLCloseComment [11:35:37.0059] Huh, I always thought the legacy HTML comments weren't supported in eval, but I don't see that represented in the spec 2023-12-16 [08:46:05.0018] > <@nicolo-ribaudo:matrix.org> Uhm, does the spec (+ AnnexB) disallow `-->` as the first line in a script? It seems so (`-->` must be preceded by a line terminator), but all browsers accept `eval("-->")` my reading of https://tc39.es/ecma262/multipage/additional-ecmascript-features-for-web-browsers.html#sec-html-like-comments agrees with this; |HTMLCloseComment| is the only nonterminal that can start with `-->` and is only valid after a |LineTerminatorSequence| (possibly wrapped in `/*ā€¦*/`). And [PerformEval](https://tc39.es/ecma262/multipage/global-object.html#sec-performeval) step 11 does ParseText(StringToCodePoints(x), |Script|), which per [ParseText](https://tc39.es/ecma262/multipage/ecmascript-language-source-code.html#sec-parsetext) and [The Syntactic Grammar](https://tc39.es/ecma262/multipage/notational-conventions.html#sec-syntactic-grammar) and [The Lexical and RegExp Grammars](https://tc39.es/ecma262/multipage/notational-conventions.html#sec-lexical-and-regexp-grammars) begins with application of the [lexical grammar](https://tc39.es/ecma262/multipage/ecmascript-language-lexical-grammar.html#sec-ecmascript-language-lexical-grammar) and should fail in the case of text starting with "-->". All implementations that I tested reject a script starting with "-->", but JSC and SM and V8 incorrectly fail to reject `eval` input that does so: ``` $ eshost -si htmlcomment.js ## Source print("HTML-like comments supported"); --> eval("/*\n*/-->\nprint('eval with leading `/**/-->` supported')"); eval("-->\nprint('eval with leading `-->` supported')"); #### ChakraCore HTML-like comments supported eval with leading `/**/-->` supported SyntaxError: Syntax error #### engine262 SyntaxError: Unexpected token #### GraalJS HTML-like comments supported eval with leading `/**/-->` supported SyntaxError: :1:2 Expected an operand but found > #### Hermes SyntaxError: invalid expression #### JavaScriptCore, SpiderMonkey, V8 HTML-like comments supported eval with leading `/**/-->` supported eval with leading `-->` supported #### Moddable XS SyntaxError: missing expression #### QuickJS HTML-like comments supported eval with leading `/**/-->` supported SyntaxError: unexpected token in expression: '>' ``` 2023-12-22 [04:39:50.0004] Is there a way to query if an object has no properties without instantiating an array? [08:10:17.0926] I've heard that in some engines Object.keys avoids an array allocation if the object hasn't de-opted and still has a hidden-class [08:10:44.0146] https://es.discourse.group/t/object-isempty/166 [08:23:11.0182] you could use for-in and skip non-own properties. but Iā€™d be surprised if the array caused issues in practice 2023-12-27 [09:33:54.0699] https://twitter.com/threepointone/status/1739997407826649239 [09:56:56.0231] fun bug. I think it's caused by optimization [09:57:20.0838] (notice 2 errors have different classes) [10:46:26.0999] yeah that's just V8 [10:46:42.0817] * yeah that's exclusive to V8 [11:00:30.0442] sounds like a great test262 test - filed https://github.com/tc39/test262/pull/3974 for that [11:01:37.0949] four space indents! _clutches pearls_ [11:02:12.0693] * four space indents! outrageous! [11:04:08.0146] two shall be the number thou shalt count, and the number of the counting shall be two. three shalt thou not count, neither count thou one, excepting that thou then proceed to two. four is right out. [11:08:10.0121] lol [11:08:27.0353] i actually use tabs, the holy indentation character, and prefer 4-space-widths anyways, but in this case it's just what vscode did automatically [11:09:13.0501] (i mainly use tabs because i value semantics and accessibility, ofc, but i'm sure spaces folks have their reasons too) [11:53:23.0172] I originally preferred tabs in favor of just configuring the editor to specify the indent appearance (which you can do with spaces as well of course), but found that they too-often were unconfigurably rendered by external viewers (esp. code review tooling) and would look atrocious with absolutely massive indentation and therefore awful readability, so.. spaces it is! [12:35:21.0290] > <@ljharb:matrix.org> sounds like a great test262 test - filed https://github.com/tc39/test262/pull/3974 for that should this be an impl-contributed test? we don't normally have optimization tests in the main suite do we? [12:35:47.0011] what is an imply-contributed test? do you mean, in the staging directory? [12:35:52.0606] we should have any regressions that have actually occurred in the main suite. [12:35:53.0020] * what is an impl-contributed test? do you mean, in the staging directory? [12:36:04.0184] [12:36:19.0793] aka v8 would fix this and add a regression test here [12:36:26.0422] ah OK so staging was renamed? [12:36:29.0737] * ie v8 would fix this and add a regression test here [12:36:34.0471] dunno [12:36:41.0807] i thought that dir was basically legacy, and staging was the new place for impls to contribute tests, and then they'd end up in the main suite [12:36:59.0447] iow, "impl-contributed" should go away, was my understanding [12:37:01.0418] i don't feel super strongly about this i just haven't seen many regression tests in the main suite [12:37:07.0900] https://github.com/tc39/test262/tree/main/test/staging [12:37:59.0405] yeah idk in the past I faced review pushback when trying to upload regression tests into test262, and I don't understand that whole thread of logic. I think we should make the tests as complete as possible, even if they are "duplicate" or unnecessary or something [12:38:33.0480] if people are going to veto it out of the main test suite, at least put it someplace that it will be run in an automated way alongside other tests. Staging does this. [12:39:11.0366] (staging is part of the main suite, that's part of the trick) [12:39:18.0920] sometimes regression tests are kinda weird because they fall into the category of denying extensions [12:39:32.0908] (this one doesn't, of course) [12:39:43.0144] > <@devsnek:matrix.org> sometimes regression tests are kinda weird because they fall into the category of denying extensions I don't care about that; I think the whole "denying extensions" thread of spec logic is incoherent [12:39:52.0871] I'm glad we've moved more towards hooks [12:40:09.0686] > <@devsnek:matrix.org> sometimes regression tests are kinda weird because they fall into the category of denying extensions * I don't care about that; I think the whole "extensions" thread of spec logic is incoherent [12:44:06.0524] > <@littledan:matrix.org> yeah idk in the past I faced review pushback when trying to upload regression tests into test262, and I don't understand that whole thread of logic. I think we should make the tests as complete as possible, even if they are "duplicate" or unnecessary or something i think i agree, this is generally the correct path. i just had an internal aesthetic struggle in that this should really covered by fuzz tests šŸ˜„ [13:31:54.0339] why not both? 2023-12-28 [18:36:43.0138] sadly i've never seen a fuzz testing solution that reliably persists failed inputs for regressions [08:25:02.0188] need `!important` for JS comments