2023-09-01 [03:05:15.0300] Apparently CLDR is not stable enough for the web: https://github.com/web-platform-tests/wpt/pull/41760. This needs some attention from Intl folks I think. littledan can you help me out finding the relevant people? [03:33:36.0266] > <@annevk:matrix.org> Apparently CLDR is not stable enough for the web: https://github.com/web-platform-tests/wpt/pull/41760. This needs some attention from Intl folks I think. littledan can you help me out finding the relevant people? Yeah this is sort of a long known, and to some extent it even provides back pressure on cldr to not change too much (which is extremely unfortunate) [03:38:39.0571] Responded on the issue, thanks for pinging me here 2023-09-04 [09:42:46.0930] in the new pattern matching, you have to specify `let` for every binding you want? 2023-09-05 [18:17:22.0268] I remember there being a W3C document giving style guidelines for DOM API design saying, e.g., “Abbreviations like HTML should be capitalized in functions’ and classes’ names.” Does this sound familiar to anyone? [18:25:50.0994] this? https://www.w3.org/TR/design-principles/#casing-rules [18:31:45.0814] snek: Perfect, this is exactly it; thank you. [19:27:32.0409] > <@devsnek:matrix.org> in the new pattern matching, you have to specify `let` for every binding you want? yes, that's the idea. instead of bindings being the default, and identifiers needing a marker, it's the reverse. [19:28:05.0479] that seems backward from practical usage in every language with pattern matching that i've used lol [19:28:55.0806] though it is hard to compare to languages with nominal typing [02:18:59.0607] > <@devsnek:matrix.org> in the new pattern matching, you have to specify `let` for every binding you want? yes, because we find it's hard to read if we create bindings by default 2023-09-06 [14:06:27.0278] Ultimately the issue is we have two things that want to use the "plain ident" space - binding patterns, and variable patterns. After a bunch of discussion, we decided that letting variables take that space resulted in a better syntax, more naturally flowing from how literal patterns worked. This also meant we didn't have to predecide what kind of binding you produced (var/let/const). 2023-09-07 [18:47:03.0721] What is plain ident? [21:45:02.0006] like `foo` - an identifier that could refer to a variable 2023-09-21 [10:47:50.0937] Has there ever been discussion of adding _very common_ functions to the standard. In particular `noop` and `identity`? Is a palatable to propose adding something like `Function.noop` and `Function.identity` to the standard, so people stop creating `() => {}` and `x => x` over and over in their libraries and codebases? [10:49:35.0890] yes [10:49:55.0975] i tried doing that early in my tc39 time, and before i even got to proposal stage nobody found it valuable. engines seem pretty good at optimizing `() => {}` [10:51:05.0641] Interesting. I mean the next thing I'd ask for would be a `Function.pipe` but given the discussion over `|>` I suspect that wouldn't go over. :) [10:52:05.0323] unrelated to pipe, that was rejected on its own merits, let me find the link [10:52:14.0994] https://github.com/tc39/proposal-function-pipe-flow [10:52:27.0008] ah, i guess not unrelated to pipe [10:54:07.0226] * ah, i guess not entirely unrelated to pipe [10:58:52.0824] Yeah, that's pretty much exactly what I'm proposing. Haha. Disappointing but not at all surprising. 😅 [11:00:07.0783] Have there been any updates to the `::` bind proposal? That's been dead-ish since about 2015, I think. [11:01:26.0789] https://github.com/tc39/proposal-bind-operator .. seems still dead. [11:04:04.0943] > <@benlesh:matrix.org> Has there ever been discussion of adding _very common_ functions to the standard. In particular `noop` and `identity`? Is a palatable to propose adding something like `Function.noop` and `Function.identity` to the standard, so people stop creating `() => {}` and `x => x` over and over in their libraries and codebases? We already have noop, it's just got a weird name `Function.prototype` 🫣 [11:06:20.0653] > <@benlesh:matrix.org> Interesting. I mean the next thing I'd ask for would be a `Function.pipe` but given the discussion over `|>` I suspect that wouldn't go over. :) I think if the syntax proposal dies there's at least some chance the stdlib function might come back, though tbh I kind of prefer reading chained arrows over reading a call to `pipe` [11:06:35.0028] > <@benlesh:matrix.org> Interesting. I mean the next thing I'd ask for would be a `Function.pipe` but given the discussion over `|>` I suspect that wouldn't go over. :) * I think if the syntax proposal dies there's at least some chance the stdlib function might come back, though tbh I kind of prefer reading chained arrows or chained calls over reading a call to `pipe` [11:06:40.0363] Haha. Yeah, I used to do that trick, but i got tired of explaining it to people. Also passing it around is like `noop.lol = 'wee'` and everyone has `fn.lol` from then on. Or `delete noop.call` [11:12:26.0761] Well, the current `|>` proposal makes me sad. I really don't like it at all... which historically means it will do well in the TC39. In fact, if you all want me to be a fortune teller, you could just point me at a proposal, and if I don't like it, it's probably going to Stage 2 minimum. If I do like it, it'll be stuck in Stage 1 forever. 😅 [11:19:39.0483] I have a proposal idea. If your fortune telling rates are resonance I'll DM you 😎 [11:19:54.0046] * I have a proposal idea. If your fortune telling rates are reasonable I'll DM you 😎 [11:20:21.0162] > <@benlesh:matrix.org> Have there been any updates to the `::` bind proposal? That's been dead-ish since about 2015, I think. yes! https://github.com/tc39/proposal-call-this [11:22:33.0036] > <@ljharb:matrix.org> yes! https://github.com/tc39/proposal-call-this I like it! Therefor it's dead at the next discussion. Sorry. [11:23:06.0071] lol [11:23:15.0800] there's a variant of it that tab has suggested as well [11:23:46.0861] fwiw i made it pretty clear at pipeline advancing to stage 2 that a requirement for going to stage 3 was something like call-this or `::` being on a likely path to advancement, if that helps [11:29:50.0622] > <@ljharb:matrix.org> fwiw i made it pretty clear at pipeline advancing to stage 2 that a requirement for going to stage 3 was something like call-this or `::` being on a likely path to advancement, if that helps I care more that I get something I can prepare for reasonably, and something that doesn't make code that is hitting libraries I'm responsible for _more_ verbose (and arguably less readable). So what happens with `|>` at this point, I guess I don't care because I have very little use for that in anything I'm working on at the moment. `~>` or the like, on the other hand ARE interesting to me, and it's plausible that RxJS and other libraries could pivot that way. [11:38:28.0426] I want neither of these things :( [11:38:53.0198] I would've been OK with pipe if there was a version which made everyone happy, but there isn't [11:39:09.0315] the call-this operator I am still confused why people think it's a good idea despite me being like a 98%ile user of `.call` [11:41:42.0766] I'd only want call-this because pipeline is wrong, TBH. I'm looking to see if there are ways to prep libraries that compose like RxJS does for either the current pipeline proposal or call-this. Current pipeline proposal isn't something people can engineer towards right now in an ergonomic way... We might be able to with call-this though. Still experimenting for my use cases. [11:44:32.0839] it's a good idea because of the order being wrong with .call, and also syntax is undeniable and robust, which is pretty important for invoking functions [11:45:35.0816] "syntax is undeniable and robust" is important to rounds-to-0% of programs [11:47:04.0935] For those programs (like Node.js core), the performance cost of uncurryThis is good to avoid. [11:47:32.0110] if you're trying to be defensive against people mutating builtins you have to run first cache all of the other standard library stuff anyway, at which point a.) your ergonomics are already shot and b.) caching `call` in addition is a very small burden [11:48:09.0477] > <@kriskowal:matrix.org> For those programs (like Node.js core), the performance cost of uncurryThis is good to avoid. you may be interested in https://github.com/nodejs/TSC/issues/1438 [11:48:50.0096] it's important to a MUCH larger percentage than that, because they transitively run code they didn't author [11:49:19.0131] the reason node wants to remove primordials isn't because robustness doesn't matter, it's because the current approach sucks for ergonomics and perf [11:49:35.0001] call-this, specifically, would be a huge benefit for node, which would help quite a lot of programs. [11:49:53.0835] just because a program has a dependency which makes use of a particular feature doesn't mean that the feature is important to the program [11:50:34.0037] it may be - as it is in this case - that the dependency is using something so that it can provide a guarantee (e.g. "robust against other code on the page messing with built-ins) which the actual program doesn't care about [11:52:17.0053] it would be odd for javascript to accept defeat as a safe sandbox language in the face of supply chain attacks when it’s the closest language to winning and the most important field to win. [11:52:22.0060] true. but the program also may only be *able* to not care about it because that guarantee is already provided without them knowing [11:52:51.0026] it's a really strange argument to me that because people don't yet care about robustness, the language shouldn't make it maximally easy and performant to be robust. [11:52:57.0699] > <@kriskowal:matrix.org> it would be odd for javascript to accept defeat as a safe sandbox language in the face of supply chain attacks when it’s the closest language to winning and the most important field to win. "you have to use `.call`" is not "accepting defeat as a safe sandbox language" [11:53:29.0637] > <@ljharb:matrix.org> it's a really strange argument to me that because people don't yet care about robustness, the language shouldn't make it maximally easy and performant to be robust. no feature that we ever add to the language is going to cause people to write anything other than `array.push`, nor should it [11:53:35.0485] you can’t use .call. You have to use uncurryThis, which frustrates optimization. [11:54:19.0729] "engines haven't optimized userland uncurryThis" is also not "accepting defeat as a safe sandbox language" [11:55:24.0329] > <@bakkot:matrix.org> no feature that we ever add to the language is going to cause people to write anything other than `array.push`, nor should it on this we agree, at least, but it doesn’t completely eliminate the need for fast call bind for some foundational code that has to run before the prototypes can be made immutable. [11:55:52.0153] engines optimizing uncurryThis would also be an acceptable outcome. [11:55:52.0631] > <@ljharb:matrix.org> true. but the program also may only be *able* to not care about it because that guarantee is already provided without them knowing they are already relying on `array.push()` working in their own program, so the fact that the dependency wants to be robust against people mutating `Array.prototype` is completely irrelevant to their program [11:56:10.0994] so, no. they are able to not care because it does not in fact matter in practice in almost any program. [11:56:32.0131] > <@kriskowal:matrix.org> engines optimizing uncurryThis would also be an acceptable outcome. A _stdlib_ proposal for `uncurryThis` and similar would be fine by me [11:56:35.0603] just not syntax [11:56:46.0163] (wasn't there one, actually?) [11:58:09.0733] ah https://github.com/js-choi/proposal-function-demethodize [11:59:33.0069] not all programs mutate arrays. [12:00:58.0059] very nearly all programs are written in a style which assumes builtins are intact. [12:01:00.0981] as well they should. [12:01:33.0622] no feature we ever add to the language is going to cause people to write in a way which does not assume that, nor should it. [12:03:30.0667] i see no argument that suggests anyone here holds the contrary position [12:03:59.0725] the specific claim I am defending is > "syntax is undeniable and robust" is important to rounds-to-0% of programs [12:04:14.0348] but i for one propose that under some conditions it is both valuable and possible to not only assume they’re in tact, but to make it possible to rely on their being in tact. [12:06:20.0555] i agree that very few existing programs rely on the immutability of shared primordials, but that’s circular. they are rare because of the economics of security, which we are in a position to adjust. [12:07:10.0622] I am ok with exploring adjustments which don't require people to completely change the style in which they write their programs, for sure [12:07:17.0812] however, that does not include the call-this proposal [12:08:07.0436] and on that, i think you and i at least agree that a non-syntactic solution is acceptable [12:10:48.0240] i merely disagree that the winning argument is based on the unimportance of defending language integrity in mutitenant (read: effectively all) programs [12:11:48.0943] the winning argument is that it’s possible to achieve that goal without syntax that a minority of programs will need to use before making intrinsics immutable [12:13:05.0112] and in some flavors, systems like airgap would prefer to accept the ergonomic cost of using a call-bind pattern pervasively _instead_ of making intrinsics immutable. [12:13:37.0233] if that's the path forward you'd also need to ensure making intrinsics immutable doesn't break everything, which is... demonstrably tricky [12:14:17.0633] for sure [12:15:13.0235] not as bad as you’d think for specific applications, but override mistake is certainly a recurring theme in herding the ecosystem into the safe subset. [12:15:51.0811] at the very least it entails replacing everything with accessors, doesn't it? [12:15:54.0764] which is... oof [13:05:11.0255] > <@kriskowal:matrix.org> i agree that very few existing programs rely on the immutability of shared primordials, but that’s circular. they are rare because of the economics of security, which we are in a position to adjust. are you threatening to hack people or what [13:27:09.0896] Notably, nothing based on classes suffers from the override mistake. So, replacing a lot of intrinsic value properties with accessors does make a lot of the problem go away. It’s far from ideal. [13:27:46.0187] well, doesn't suffer from the override mistake as long as you declare all your fields, anyway [13:27:53.0789] aye. [13:37:58.0645] > <@shuyuguo:matrix.org> are you threatening to hack people or what I hacked a computer once. I locked my dad out of a 486 by putting an infinite loop in AUTOEXEC.bat. And echoing out some ANSI that remapped Y and N to *. And also making the foreground color black. [13:38:51.0243] > <@shuyuguo:matrix.org> are you threatening to hack people or what * I hacked a computer once. I locked my dad out of a 486 by putting an infinite loop in AUTOEXEC.BAT. And echoing out some ANSI that remapped Y and N to \*. And also making the foreground color black. [14:42:54.0917] > <@bakkot:matrix.org> at the very least it entails replacing everything with accessors, doesn't it? I still believe we can arrive at an override mistake fix, at least for the use case that matters of a frozen prototype chain, that does not require making everything in those prototype chains accessors. One option would be to record the frozen choice on the object (like an integrity level), and fallback to the set on receiver if the prototype object is in that state. We don't even need to conflate the current frozen state with this new state, which could be an "extra-frozen" level instead. [14:51:04.0383] right, yes, fixing the override mistake is also an option [15:30:37.0923] What exactly is "the override mistake"? Trying to search it on google even adding "javascript" as keyword only yields irrelevant results [15:32:50.0187] voidhedron: `'use strict'; var o = ({ __proto__: Object.freeze({ foo: false }) }); o.foo = true;` it throws, instead of defining an own property on `o` [15:32:50.0994] There’s a mention here https://exploringjs.com/deep-js/ch_property-assignment-vs-definition.html [15:41:10.0502] https://github.com/tc39/how-we-work/blob/c96099d8ab460b933bd80d65b8b4c6a05ee0c791/terminology.md#override-mistake [15:53:18.0821] > <@ljharb:matrix.org> voidhedron: `'use strict'; var o = ({ __proto__: Object.freeze({ foo: false }) }); o.foo = true;` it throws, instead of defining an own property on `o` Ah interesting, I think I may have accidentally ran myself into that once or twice [15:56:45.0668] that's an understatement actually, looking back on my code now [15:58:05.0893] I actually enjoy using nodejs with their `--frozen-intrinsics` flag for personal projects, so a lot of my code is written to handle that but I've just never recognized it as a well known pattern (mainly because it's caused by an experimental flag which I assume very few use) [15:58:53.0402] it also breaks a surprising number of packages, due to the override mistake. [15:59:24.0874] * it also breaks a surprising number of packages, due to the override mistake (often transitive deps, not because lots of *code* breaks from it) [16:01:53.0460] Yeah I'm aware, it may or not be related to the fact that I am also very packagephobic, at least at runtime, devDependencies all good, I pull in tsc and stuff whatever, but runtime deps I avoid as much as possible and always thoroughly review any I pull in, and when I do I only use zero or low dependency ones so I can avoid issues related to that and other things :P [16:02:43.0108] I also often just copy the specific parts of a package I actually want directly into my code so I can adapt it into my hardened-JS-style I prefer [16:03:31.0899] I actually have a helper function I created that I guess solves the "override mistake" although I didn't realize it was known as that when I did it [16:09:51.0002] it's not that complex: ```js function setOwnKey(o, key, value) { const p = Object.getPrototypeOf(o); Object.setPrototypeOf(o, null); o[key] = value; Object.setPrototypeOf(o, p); } ``` it works for anything as long as `o` itself is not frozen, only its prototype [16:10:29.0961] has TC39 ever considered just adding a function like this to solve the "mistake"? [16:10:39.0494] like `Reflect.setOwnKey` [16:11:12.0541] opt-in fixes won't fix the mistake; the mistake is that it proliferates in shipped code that's not updated [16:11:20.0339] you can already opt-in to use define instead of set semantics to work around [16:12:39.0805] ah I see, fair enough [16:13:04.0043] and then you don't have to change the prototype of your thing [16:13:18.0245] which you generally want to avoid for optimization reasons 2023-09-22 [21:32:51.0280] i'm going to go one step further and say that it is a good desirable property of the js ecosystem that most programs are not written defensively [21:34:46.0282] being able to modify and mess with stuff is fun and useful [22:00:58.0048] that, i disagree with hugely [22:01:17.0260] you can edit the code on disk or in the debugger all you like, but it's a disaster that so many things are mutable at runtime 2023-09-26 [15:29:40.0021] does anyone know of any languages or frameworks that have coverage analysis of values instead of lines? like say you have `fn add(a, b) { ... }`, just calling `add()` in a test wouldn't be enough, you need to actually observe the returned value in an assertion like `assert add(1, 2) == 3` or something... [15:37:13.0786] hmmm https://en.wikipedia.org/wiki/Concolic_testing [16:49:28.0540] that sounds great but i'm not sure how you could actually *do* that in JS [16:49:42.0003] * that sounds great but i'm not sure how you could actually _do_ that with JS [16:49:47.0088] * that sounds great but i'm not sure how you could actually _do_ that for JS 2023-09-27 [18:21:49.0658] well it happens that facebook wrote a js engine that uses symbolic execution [18:21:58.0054] so its not impossible to test out at least 2023-09-28 [22:12:05.0305] https://github.com/tc39/ecma262/issues/1801 is quite confusing, do I use [[ArrayLength]] or [[ByteLength]] for typed arrays? [22:12:26.0797] I guess they are different [22:12:41.0468] But some parts of the spec pretend there is no [[ByteLength]] for them [22:18:15.0814] ArrayLength is scaled to the element size of the typed array, ByteLength is on ArrayBuffers [22:42:49.0191] [[ByteLength]] is also on typed arrays, according to some parts of the spec. [22:42:59.0618] e.g. https://tc39.es/ecma262/#sec-get-%typedarray%.prototype.bytelength [22:44:08.0427] But not https://tc39.es/ecma262/#sec-integer-indexed-exotic-objects [22:44:50.0549] oh right, argh [22:45:04.0268] would be nice to clean up to not cache things, i guess [00:20:16.0913] Does anyone know of a website with COOP and COEP enabled? it's hard to find one to experiment with SAB [00:49:10.0809] Jack Works: https://microsoft.github.io/z3guide/docs/logic/intro/ [00:49:45.0310] it uses https://github.com/gzuidhof/coi-serviceworker [01:07:54.0040] 🤔