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:

  • there is no timing issue in HTML, two parallel requests are deduped if they are for "the same module"
  • import type text and import "type js" always result in two requests in HTML. It's unambiguous that it happens, and it's also if they happen not in parallel
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:

In this specification, the noun "content" is used in three ways:
It is used to mean the document object as a whole or in parts.
It is used to mean the content of an HTML or XML element, in the sense employed by the XML 1.0 specification ([XML], section 3.1): "The text between the start-tag and end-tag is called the element's content." Context should indicate that the term content is being used in this sense.
It is used in the context of the phrases non-text content and text content.

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>
class A {}
class B extends A {}
B instanceof A // false
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:

protocol Stringable {
  toString;
}

You could potentially implement it in a class like either:

class C1 implements Stringable {
  toString() {} // implicit
}
class C2 implements Stringable {
  [Stringable.toString]() {} // explicit
}

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.:

class C1 implements Stringable {
  toString() { ... } 
}
// runtime generated
Object.defineProperty(C1.prototype, Stringable.toString, Object.getOwnPropertyDescriptor(C1.prototype, "toString"));

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
Poor Tom