| 13:56 | <Rob Palmer> | Hey all |
| 13:57 | <Rob Palmer> | We are starting in two minutes! |
| 13:59 | <Ashley Claymore> | Reminder: Please add yourself to the attendees section of day two of the notes |
| 14:06 | <Chris de Almeida> | Ladybird == LibJS right? |
| 14:07 | <ryzokuken> | Ladybird is the browser and LibJS is the JS interpreter |
| 14:13 | <Ashley Claymore> | https://ladybird.org/posts/adopting-rust/ |
| 14:31 | <Aki> | from the perspective of multiple other standards that normatively reference exclusively the regex portion of the standard… can we come back to that question in the future? |
| 14:34 | <Aki> | Reminder that ECMA-414 exists, and functionally exists to lay out all the standards required to implement all of standardised ECMAScript |
| 14:35 | <Michael Ficarra> | a single document that contains all web specs sounds nuts |
| 14:36 | <waldemar> | Getting Internal Server Errors on TCQ |
| 14:36 | <Aki> | ooh but an ECMA-414-style document for the web eyebrows eyebrows |
| 14:44 | <Richard Gibson> | ECMA-426 normatively references ECMA-262 regular expression machinery: https://tc39.es/ecma426/#sec-MatchSourceMapURL |
| 14:44 | <Aki> | as does 424, and 42…9? maybe? and a bunch outside of Ecma |
| 14:45 | <ljharb> | why? i want it very much |
| 14:45 | <ljharb> | if it's not nuts to put it all in the same app, then it shouldn't be nuts to put it in the same doc :-p |
| 14:46 | <Richard Gibson> | where would you even establish the cutoff? Does it include HTTP? WebSocket? DNS? QUIC? |
| 14:48 | <ljharb> | everything. i want a single document that defines everything a web browser needs to be compliant. |
| 14:48 | <ljharb> | iow i don't agree with "you have to draw a line somewhere" - you can just not draw a line |
| 14:48 | <Richard Gibson> | clarified above, I was specifically referring to other specs referencing ECMA-262 regular expressions |
| 14:48 | <Aki> | as was i |
| 14:48 | <Richard Gibson> | oh, I didn't see any reference to regular expressions in ECMA-424 |
| 14:49 | <Richard Gibson> | in that case, good luck to you |
| 14:49 | <Aki> | oh 427 is what i meant |
| 14:49 | <Aki> | too many numbers |
| 14:50 | <Richard Gibson> | the POSIX specification is at https://pubs.opengroup.org/onlinepubs/9799919799/ , and ISO C is https://www.iso.org/standard/82075.html |
| 14:50 | <nicolo-ribaudo> | It also references a bunch of other stuff, like Call and JSON.parse |
| 14:51 | <Aki> | The next Ecma standard will indeed be ECMA-435 |
| 15:03 | <nicolo-ribaudo> | jkup: What does SME mean? |
| 15:03 | <Zb Tenerowicz (ZTZ/naugtur)> | Can I express my unconditional support for advancing Error code property to all stages requested, in case I'm unavailable to do it synchronously? |
| 15:04 | <Richard Gibson> | Subject Matter Expert |
| 15:04 | <jkup> | sorry |
| 15:04 | <jkup> | I just like the idea a lot of trying to make sure we have a regex/intl/temporal person always on the editor group |
| 15:05 | <Michael Ficarra> | as another example: we often run into ambiguities and as editors need to figure out the committee-ordained normative behaviour so we can make editorial clarifications |
| 15:05 | <nicolo-ribaudo> | ty :) |
| 15:06 | <jkup> | I think there is general ambiguity around when to task group, when to just have a subgroup meeting, when to just have an editor who is a subject matter expert |
| 15:16 | <Aki> | I wanna say 8½ years since stage 2 |
| 15:17 | <James M Snell> | The "it's about time" jokes write themselves |
| 15:17 | <Aki> | (which also means i've been involved with TC39 for 8½ years and that doesn't seem right) |
| 15:17 | <bakkot> | there's a lot of things like that; big ones that come to mind are unicode, parsing, atomics, and module machinery |
| 15:17 | <Ashley Claymore> | Incredible work by the champion group and the committee as a whole! |
| 15:17 | <bakkot> | prior editor group did not have great coverage for module machinery |
| 15:18 | <Shark> | Very happy for Temporal being stage 4 now! |
| 15:21 | <snek> | oh that's very exciting 🥳 |
| 15:22 | <bakkot> | Chris de Almeida: there's the TG3: Security (5m, Chris de Almeida) item if you really want something to go in the time slot |
| 15:23 | <Chris de Almeida> | thanks! |
| 15:26 | <bakkot> | https://docs.rs/jiff/latest/jiff/ is the rust library based on Temporal if anyone's curious |
| 15:27 | <nicolo-ribaudo> | Do that one and temporal_rs rely on each other, or are they independent? |
| 15:27 | <bakkot> | independent |
| 15:27 | <Michael Ficarra> | it's a shame that's not an image manipulation library for gifs |
| 15:27 | <bakkot> | slightly different design decisions - temporal_rs assumes you're providing your own tzdata IIRC |
| 15:32 | <rbuckton> | Olivier, thanks for having someone at V8 look over the buffer boundaries proposal. |
| 15:33 | <Chris de Almeida> | oh man, eemeli I don't know how you're gonna follow that one up after the break 😅 |
| 15:35 | <James M Snell> | I'm working on the discussed updates for the typedarray find within proposal and I'm stuck on figuring out alternative names as discussed... the request was that we find a name that clearly represents that we're looking for a subsequence... other than the Too-On-The-Nose findSubsequence which works but makes me cry a little, I'd love folks to suggest some alternatives colors for the bike shed. |
| 15:36 | <bakkot> | surely indexOfSequence, find means something else |
| 15:36 | <eemeli> | I'm rather hoping that import-text will be a counterpoint, an example of how a proposal can get implemented across multiple specifications in a record short time, rather than nearly a decade... |
| 15:36 | <rbuckton> | +1 |
| 15:36 | <rbuckton> | findX in most of the core spec tends to mean "look for the element via a predicate callback function" |
| 15:37 | <nicolo-ribaudo> | I actually don't mind Sequence in the function name |
| 15:37 | <bakkot> | honestly, indexOfSequence would be ok by me. it's clear, at least. |
| 15:37 | <bakkot> | ("subsequence" is overkill tho) |
| 15:37 | <rbuckton> | I think indexOfSequence is fine, though on the surface it leads me to believe that iterables and arrays might be an option. |
| 15:37 | <nicolo-ribaudo> | Or Chunk which is shorter |
| 15:37 | <bakkot> | (part of my motivation is that I am still kind of hoping they can be an option later) |
| 15:38 | <nicolo-ribaudo> | indexOfChunk, includesChunk |
| 15:38 | <rbuckton> | That's not a huge issue. I'd say indexOfSubarray, except .subarray() has a specific meaning that might be at odds |
| 15:38 | <Michael Ficarra> | indexOfSequence WFM |
| 15:42 | <James M Snell> | ok, that's multiple votes for indexOfSequence ... works for me |
| 15:42 | <James M Snell> | thanks all |
| 15:43 | <bakkot> | ... you know... we could technically overload indexOf. it does strict equality for the needle (no coercion) so TA.indexOf(otherTA) will always return false, and it's possible no one is relying on that |
| 15:43 | <bakkot> | but, new method is probably better, I guess |
| 15:52 | <rbuckton> | While I think supporting arbitrary iterables is perhaps overkill, it's unfortunate that u8.indexOfSequence([0, 1, 2]) would be disallowed for convenience. |
| 15:55 | <Shark> | I don't think that's fully true. temporal_rs (currently still) relies on jiff-tzdb, but however it is optional |
| 15:57 | <bakkot> | oh, neat, I hadn't realized |
| 16:09 | <nicolo-ribaudo> | Richard Gibson: He mant a different Sec-Fetch-Dest header |
| 16:10 | <nicolo-ribaudo> | (and maybe Accept, but I believe that both use */*) |
| 16:10 | <ljharb> | right - what i would prefer is that it be impossible to distinguish on the server which import type is being used, for all of json, text, and bytes |
| 16:14 | <bakkot> | what's the purpose of deliberately withholding information from the server (or service workers)? |
| 16:15 | <ljharb> | because that information shouldn't be needed, or branched on |
| 16:15 | <bakkot> | why not |
| 16:16 | <Richard Gibson> | perfect, that's what I was looking for |
| 16:16 | <bakkot> | there was, e.g., a specific request to allow servers to only serve javascript as a script, which I think is totally reasonable? |
| 16:16 | <ljharb> | why would we want to allow a scenario where importing something gets you different conceptual content based on the type? The point of type is only to change the representation of the data - you shouldn't have to expect the underlying data might differ based on the type |
| 16:17 | <bakkot> | that is the entire point of the Accept header |
| 16:17 | <bakkot> | and type is similar |
| 16:17 | <ljharb> | to allow that? yes, i realize |
| 16:17 | <nicolo-ribaudo> | Oh also:
|
| 16:18 | <ljharb> | good to know; why does that always result in 2 requests tho? |
| 16:18 | <bakkot> | the example I have in mind is "you can only load this JS file as a script" which seems pretty reasonable? |
| 16:18 | <ljharb> | if the module is already cached then there shouldn't be a need for another one |
| 16:18 | <nicolo-ribaudo> | Because their cache is (URL, type) and not just URL |
| 16:18 | <nicolo-ribaudo> | Because the type affects the headers |
| 16:18 | <nicolo-ribaudo> | Because they want it to affect them |
| 16:18 | <ljharb> | the feature for importing as text, or as bytes, is the language saying that no, that's not reasonable |
| 16:18 | <bakkot> | uh |
| 16:18 | <bakkot> | I... do not take the feature to mean that |
| 16:19 | <ljharb> | can you explain why you'd only want a JS file to load as a script? (given that that's only a blocker for import, and not for fetch?) |
| 16:20 | <ljharb> | like what use case do you have where it's fine that they read the text with fetch, but not with import? |
| 16:20 | <bakkot> | fetch does not and cannot have a sec-fetch-dest of script, so it is also a blocker for fetch |
| 16:20 | <ljharb> | ah, ok, TIL |
| 16:20 | <ljharb> | and there's no way with service workers to read it as text? |
| 16:20 | <bakkot> | (the sec- prefix means you can't set it from a script by any means) |
| 16:21 | <ljharb> | (obv there's always "another server" that can get it as text and proxy it down) |
| 16:21 | <bakkot> | I think you could register a service worker which could read it as text if you are in a position to do so, but there are plenty of applications which don't allow you to register a service worker |
| 16:22 | <ljharb> | either way i'd rather "this file can only be loaded as a script" be a header sent by the server, where the browser chooses how to obey it, than have the server change the response based on how it's being imported |
| 16:22 | <ljharb> | (which also aligns better with the web's philosophy of "the user and user agent is in control, not servers") |
| 16:22 | <bakkot> | well, sec-fetch-dest already exists, is already script for import and <script>, and is already not script for fetch |
| 16:23 | <ljharb> | so because there's a pre-existing bad design, it must be continued? |
| 16:23 | <bakkot> | so your ask is, we already have this perfectly good mechanism which enforces this invariant, and we should stop doing so because you want servers not to have this power? |
| 16:23 | <ljharb> | because it's not perfectly good |
| 16:23 | <ljharb> | it delegates control to the server instead of the user, which contradicts HTML philosophy |
| 16:24 | <bakkot> | I don't know what philosophy this is referring to. generally the web platform does not seek to deny information from servers |
| 16:24 | <ljharb> | https://www.w3.org/WAI/UA/WD-UAAG10-TECHS-20010604/guidelines.html#gl-content-access and a few other guidelines in that doc, for one |
| 16:25 | <ljharb> | the underlying principles of all the "Ensure user control" items is that the user should always be in charge |
| 16:26 | <bakkot> | the user can still view the script as a string, it's just the web application that doesn't get to |
| 16:26 | <bakkot> | "view source" still works fine |
| 16:26 | <rbuckton> | Except that browsers already enforce strict mime type checking for things like scripts, so you can't run a script whose header is text/plain and the only real workaround is to change the mime type on the server. |
| 16:27 | <bakkot> | also, scripts are not "content" in the sense meant by this guideline:
|
| 16:28 | <rbuckton> | These are security invariants that are important to protect against bad actors attempting to smuggle in scripts under unexpected mime types |
| 16:28 | <ljharb> | i understand the current reality, and it is perfectly reasonable to prevent unexpected execution of code. that doesn't mean the current reality needs to be extended to new language features, and in this case, i can smuggle in scripts and eval them just fine with or without the behavior i want |
| 16:29 | <ljharb> | this mechanism isn't preventing that, it's just preventing me from being able to reliably inspect a resource that the browser otherwise executes/renders |
| 16:31 | <bakkot> | you already do not have that ability, so it's a request to specifically enable you do to do this thing which you could never previously do |
| 16:31 | <ljharb> | iow imo this allows more smuggling in of code - because the web application can't inspect code before executing it. |
| 16:31 | <bakkot> | I don't think we should have that as a goal of this feature |
| 16:31 | <ljharb> | i mean i can already do it with fetch or other means unless the server doesn't want me to, right? |
| 16:32 | <bakkot> | right but you can also do it with this feature unless the server doesn't want you to |
| 16:32 | <bakkot> | the requests made with this feature look basically like the requests made by fetch |
| 16:32 | <bakkot> | for the bytes proposal they look exactly like those requests IIUC |
| 16:32 | <ljharb> | hm |
| 16:33 | <ljharb> | so i think my objection isn't so much that servers can deny inspection, it's more that they can lie - meaning you can choose to send different code |
| 16:34 | <bakkot> | sending different data in response to different requests isn't lying |
| 16:34 | <nicolo-ribaudo> | You could have a web page that serves HTML, CSS, JS, and a picture all at the same URL :) Why waste URLs for the various things |
| 16:35 | <ljharb> | i mean you could, but does anyone do that? |
| 16:35 | <ljharb> | not inherently. but it certainly could be |
| 16:35 | <rbuckton> | Many sites do. |
| 16:36 | <rbuckton> | You can often have an endpoint that serves REST or WSL or HTML based on the Accepts header. It happens all the time with CMS |
| 16:37 | <bakkot> | it's pretty common to serve machine-readable data if the Accepts header asks for json |
| 16:37 | <bakkot> | also I have seen at least a few sites serve markdown if the Accepts header asks for markdown, as an affordance for LLMs |
| 16:37 | <ljharb> | true. but if that data doesn't conceptually match the non-JSON resource i'd call that "lying" |
| 16:40 | <Michael Ficarra> | everything behind Cloudflare https://blog.cloudflare.com/markdown-for-agents/ |
| 16:42 | <rbuckton> | Besides, varying data by an Accepts header is no different than varying data by a Cookie header, and the latter is also used all the time to serve different content based on whether you're signed in. |
| 16:43 | <ljharb> | i do think it's different |
| 16:44 | <ljharb> | Accepts is intended to change the representation of a resource, and indeed a URL is intended to map to a single resource. that some CMS's abuse that to serve wildly different content at a URL doesn't change that |
| 16:44 | <Richard Gibson> | the real shame is disregard for a Vary header field, which AFAIK is mandated for distinct destinations |
| 16:44 | <rbuckton> | Sites also often vary data by Referer |
| 18:00 | <Aki> | obligatory for takingnotes.rocks |
| 18:17 | <waldemar> | knot is not a measure of length |
| 18:21 | <Ashley Claymore> | but the knots should be spaced 47 feet 3 inches apart |
| 18:28 | <waldemar> | The code on the slides is very hard to read due to low contrast — it's too close to the background color |
| 18:33 | <danielrosenwasser> | @justingrant:matrix.org I think there was a misunderstanding- code on DOMExceptions are numbers, "code" in someDomException is true |
| 18:37 | <nicolo-ribaudo> | Very much looking forward to the long bikesheds about the built-in error codes in every proposal |
| 18:38 | <bakkot> | I was kind of hoping we could agree not to have codes for built-in errors |
| 18:38 | <bakkot> | they significantly constrain implementations |
| 18:40 | <nicolo-ribaudo> | Chris de Almeida I'd prefer my topic on the queue to go after stage 1 advancement |
| 18:48 | <nicolo-ribaudo> | Not to gatekeep words, but this sugar is not syntactic! |
| 18:49 | <Ashley Claymore> | API syrup? |
| 18:52 | <nicolo-ribaudo> | We had a "catch a specific error type proposal" right? What happened to it? |
| 18:53 | <bakkot> | got folded into match expressions IIRC |
| 18:53 | <ljharb> | not exactly; it was deferred until pattern matching advances. but close enough |
| 19:05 | <waldemar> | Seems that we have a bit of a timeslot fragmentation problem for the remainder of the meeting — plenty of long underflows that can't be filled due to items requesting 60 or 90 contiguous minutes |
| 19:08 | <bakkot> | I don't actually need 90 contiguous minutes for mine |
| 19:11 | <Aki> | Now seems like a great time for everyone to update their summaries and conclusions |
| 19:18 | <bakkot> | was "november 24" supposed to be "november 2024" or "november 24 2025" |
| 19:18 | <Rob Palmer> | Chris is working with the speakers to defrag. |
| 19:24 | <Chris de Almeida> | check again |
| 19:25 | <Chris de Almeida> | bakkot: Evan Winslow your topics have been scheduled. as always, things may still change, esp if time frees up |
| 19:25 | <bakkot> | <3 |
| 19:59 | <bakkot> | yup the delay in the transcription is definitely on the google docs end, which apparently has a p99 latency of like 10 seconds |
| 20:00 | <bakkot> | real-time almost word-perfect transcriptions over a web socket? easy. updating text with simple HTTP post? apparently somehow more difficult |
| 20:10 | <jkup> | My web browser can’t access app.element.io. My Element X app appears to have access. Anyone else? I realize it’s weird asking about a chat outage on the chat app. |
| 20:10 | <nicolo-ribaudo> | Oh hello to those whose matrix works |
| 20:13 | <Chris de Almeida> | happy matrix working again to all whom's't've celebrate |
| 20:14 | <Shark> | Interesting that Matrix doesn't show anything on their status page, at least not yet |
| 20:19 | <rbuckton> | The last chunk of test262 tests for resource management have been merged. |
| 20:20 | <rbuckton> | Just need to wrap editorial review |
| 20:20 | <Michael Ficarra> | yeah I hear you |
| 20:24 | <Chris de Almeida> | bikeshed nit: not much a fan of requires due to require in cjs |
| 20:27 | <rbuckton> | IMO, we probably don't need a new keyword for the test. instanceof could be used for this just fine, as could (potentially) pattern matching via is |
| 20:29 | <Michael Ficarra> | https://github.com/tc39/proposal-first-class-protocols/issues/69#issuecomment-3721525589 |
| 20:31 | <ljharb> | instanceof would definitely be inappropriate to use imo, since it'd overload the existing meaning. |
| 20:32 | <bakkot> | it seems like exactly the existing meaning? |
| 20:32 | <ljharb> | @erights Mark Miller (Agoric) MM: unique symbols |
| 20:32 | <ljharb> | Promise is a thenable but it's an instanceof Object, they're different |
| 20:32 | <rbuckton> | Hmm, I may have misunderstood. I see this was a check against the constructor. C implements P at the constructor level seems weird |
| 20:32 | <ljharb> | instanceof is about inheritance; protocols aren't |
| 20:32 | <bakkot> | no one cares about inheritance, it's just "is a" |
| 20:33 | <rbuckton> | instanceof is just fine from a type theory perspective. |
| 20:33 | <ljharb> | it is very much not just "is a" in JS, and either way, protocols add a second way of "being", and they shouldn't be conflated |
| 20:34 | <bakkot> | why not |
| 20:34 | <ljharb> | because then you can't reason about which check it's doing? |
| 20:34 | <rbuckton> | People often reach for instanceof. I would want Cobj instanceof P to work just fine. |
| 20:34 | <ljharb> | you can define Symbol.hasInstance if you want that, but that definitely must not be the default behavior |
| 20:34 | <rbuckton> | Then again, if we can get is with pattern matching, I'd much rather spell this as Cobj is P, so maybe my position on instanceof isn't quite as string. |
| 20:35 | <bakkot> | there is no case where this would be unclear |
| 20:35 | <ljharb> | (also, implements wouldn't have a protocol hook, which is also good - instanceof is not an option solely due to that imo) |
| 20:36 | <ljharb> | i'm not sure why? protocols can extend other protocols too. |
| 20:36 | <bakkot> | classes extending other classes do not thereby become instanceof those classes |
| 20:36 | <ljharb> | (and is as proposed would also invoke a protocol, which also means it shouldn't be an option here) |
| 20:37 | <Michael Ficarra> | no, that was a typo |
| 20:38 | <ljharb> | unless you do return override or define Symbol.hasInstance, they do? |
| 20:38 | <rbuckton> | @ljharb, another perspective: Suppose today I have an inheritance hierarchy where D extends C, C extends B, and B extends A and I have an instance d of D. If I have code today that does d instanceof B and decide B is better as a protocol, I cannot refactor it without breaking consumers if instanceof does not support protocols. |
| 20:38 | <bakkot> |
|
| 20:38 | <ljharb> | oh you mean the constructors |
| 20:38 | <ljharb> | you can, by defining Symbol.hasInstance |
| 20:39 | <rbuckton> | That's esoterica I don't expect the average developer to reach for. |
| 20:39 | <ljharb> | (but i also wouldn't expect refactoring between a class and a protocol to be transparent) |
| 20:46 | <rbuckton> | If it matters, C# uses : for both specifying a superclass as well as interfaces, i.e. class C : A, I {}. You could theoretically just do C extends A, P {} and have ClassDefinitionEvaluation look at whether each item corresponds to a function (superclass) or protocol. |
| 20:47 | <ljharb> | true. but then we'd either have to throw for more than one non-protocol, or allow multiple inheritance, and i would strongly object to the latter |
| 20:48 | <rbuckton> | Throw for more than one non-protocol is perfectly reasonable. That's the same as C#'s semantics |
| 20:52 | <Evan Winslow> | Protocol is more "abstract class" than "interface"? IIUC... |
| 20:54 | <Chris de Almeida> | queue is captured |
| 20:56 | <rbuckton> | Many "interface" implementations in multiple languages now support supplying default behavior, but they also generally similar to "abstract" in many ways. |
| 20:57 | <Evan Winslow> | Yea good point. I am more used to TS which distinguishes abstract class and interface, so I was thinking in those terms. |
| 21:02 | <rbuckton> | I sometimes wonder about the potential for something like C#'s approach to implicit vs explicit interface implementation, such that implementing an interface could use an identifier-named member as a shorthand for the more explicit symbol-named member. For example, if you had something like:
You could potentially implement it in a class like either:
In the first case, implementing the protocol would look first look for the explicit implementation and then for an identifier with the same name. If an explicit member didn't exist, it would be added as an alias to the identifier-named member, i.e.:
That might make the dichotomy between identifier and symbol a bit less of a problem. |
| 21:15 | <Justin Ridgewell> | We need TCQ |
| 21:18 | <Lea Verou> | Yup, that was also discussed at some point. Can't remember the reasons we didn't go with it, maybe Michael Ficarra does |
| 21:18 | <Aki> | don't forget your summaries and conclusions! 😆 |
| 21:18 | <Lea Verou> | Ah, just saw he shared the issue! |
| 21:19 | <nicolo-ribaudo> | Is that an uppercase P? 😭 |
| 21:19 | <Shark> | that looks very delicious! |
| 21:20 | <Shark> | I only wonder what would have happened with the cake when Temporal wouldn't be Stage 4 now 😅 |
| 21:33 | <Chris de Almeida> | yes! |
| 21:33 | <Chris de Almeida> | Tem Poral is Stage 4 |
| 21:33 | <Chris de Almeida> | 🤣 |
| 21:34 | <Andreu Botella> | wait, are we finding out the objectively correct pronunciation after stage 4? /s |
| 21:49 | <rbuckton> | Tem Poral is Stage 4 |