2021-07-01 2021-07-02 2021-07-03 [13:23:39.0143] bakkot: do you know what this means? https://gc.gy/93048818.png [13:33:08.0363] Multiple linebreaks in a

? [13:33:33.0965] (See https://github.com/tc39/ecmarkup/issues/226) [13:36:26.0726] * Multiple linebreaks in a

? I.e., an empty line within a

element. [13:48:28.0111] hmm i don't see any

s with linebreaks [13:48:35.0350] maybe i'm being dum 2021-07-04 [21:40:43.0289] devsnek: it's two linebreaks in the the ``` An object that all standard built-in iterator objects indirectly inherit from

The initial value of the *"prototype"* data property of %Iterator%; i.e., %Iterator.prototype%

``` bits [21:41:04.0597] ecmarkup ought to give location information; odd that it doesn't [21:42:09.0955] seems to be because it's in a table, though I don't know why that should prevent it from giving location information [21:42:31.0099] oh, no, I do know why [21:42:32.0383] sigh [21:59:55.0512] https://github.com/tc39/ecmarkup/pull/329 has a fix so that ecmarkup will properly give location information for this case [22:00:24.0543] anyway the actual fix is to delete one of the linebreaks in the above snippet, and the same in the other place that happens [22:00:34.0218] ecmarkdown is sensitive about multiple consecutive linebreaks, for some reason 2021-07-05 [17:53:11.0613] what a weird snippet! [17:53:44.0431] is that ecmarkdown? [17:54:09.0946] it's HTML [17:54:45.0099] hmm, i know markdowns accepts html [17:55:28.0880] so, ecmarkdown must be a custom markdown format [17:55:43.0046] i have never used it [17:56:42.0593] ecmarkdown is used by ecmarkup in the process of rendering the specification to HTML [17:56:56.0515] i figured [17:58:31.0879] is it based on markdown? Going to have to read up on this [17:58:47.0857] vaguely, yes [19:08:12.0142] * hmm, i know Markdown accepts html 2021-07-06 2021-07-07 2021-07-08 [20:26:21.0908] bakkot: there is no example for `emu-eqn` https://tc39.es/ecmarkup/#emu-eqn [20:34:24.0955] Well, it does point to examples in the ES spec. [20:36:04.0730] yeah, i guess that's ok [20:36:31.0469] makes me load an enormous document, but ok lol 2021-07-09 2021-07-10 [10:00:21.0312] loads fast everywhere but chrome :-p 2021-07-11 [13:14:37.0156] ljharb: im not attending next meeting and you are partially to blame [13:28:42.0658] more accurately: i had some plans come up, so im going to fight about it [13:37:12.0191] * more accurately: i had some plans come up, so im not going to fight about it [14:43:09.0088] - 13th: unavailable all day - 14th: doubt i will feel up to going to that - 15th: we'll see what happens 2021-07-12 [21:16:21.0698] DerekNonGeneric lol how am i to blame? [21:17:19.0320] I feel that it's likely that the meeting will finish on the 14th or the 15th at the latest... [21:18:23.0934] but yeah, probably a two-day meeting this time. [21:36:04.0261] /me is in pacifist mode [03:42:00.0960] > <@dereknongeneric:mozilla.org> ljharb: im not attending next meeting and you are partially to blame I'm confused; are you a delegate or invited expert? [03:56:54.0084] What happened šŸ‘€ [10:43:00.0200] this thing isn't even happening, so im not mad or anything [12:14:05.0686] > <@dehrenberg:igalia.com> I'm confused; are you a delegate or invited expert? you can put me down as an IU delegate [12:14:45.0540] > <@jackworks:matrix.org> What happened šŸ‘€ not exactly sure tbh [12:19:48.0360] DerekNonGeneric: Our typical process is that the person running the organization's Ecma membership should enroll you by filing an issue at https://github.com/tc39/Admin-and-Business/issues . I don't see an issue there yet; I suggest you get in touch with the appropriate person in IU. [12:20:49.0426] littledan: we started a thread about this in IRC (facility now blocked) -- the man is very busy, so i don't want to impose [12:20:50.0810] * DerekNonGeneric: Our typical process is that a person involved in the organization's Ecma membership should enroll you by filing an issue at https://github.com/tc39/Admin-and-Business/issues . I don't see an issue there yet; I suggest you get in touch with the appropriate person in IU. [12:21:53.0807] hmm, maybe you could convince him to explicitly delegate to someone else, but anyway, I'm just speculating, and this is all up to the chairs. [12:22:36.0583] (we're busy too!) [13:32:37.0021] sent him an email from my student account 2021-07-13 [18:07:21.0348] It seems I don't have permission in TC39-delegate room šŸ˜‚ [18:45:57.0071] ryzokuken: See https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-JSON for one explanation of why there are multiple JSON standards. [18:47:01.0594] thanks jmdyck [23:42:55.0592] is https://wiki.ecmascript.org still active? [23:43:23.0578] response to https://wiki.ecmascript.org/doku.php?id=harmony:proxies just timing out [00:02:07.0223] nope, i don't have details, but that is not a tc39 web property [03:46:21.0862] So, that ES wiki is definitely a site created by TC39, but it is indeed down, and we access it through, umm, internet archive [07:50:52.0449] littledan we should link to it from the site then (eventually) [08:04:16.0081] Well, it's more of a historical archive [08:04:34.0454] Not all pieces of TC39 history are linked from the site [08:04:44.0151] The main priority IMO is to archive it well [10:06:39.0718] jmdyck not sure if you saw my reply on https://github.com/tc39/ecma262/pull/2125#discussion_r668431272 - it'd really help to get a concrete suggestion to get this over the line :-) [10:08:01.0853] Nope, I've been busy all day so far. [10:10:03.0411] Will do something now. [10:10:14.0648] yay, thanks :-) not a huge rush ofc, just trying to get it done [10:10:24.0896] np [10:54:45.0743] Done. [11:18:39.0672] jmdyck: thanks! updated :-) 2021-07-14 [19:20:59.0393] how does one get access to TC39 Delegates? [19:21:53.0236] one of the admins need to change your access level so you can talk [23:22:10.0001] Aki: World's first make-your-own KitKat shop opening in Tokyo! :D [23:22:25.0779] ooh [23:34:12.0702] shut up [03:50:30.0735] this is interesting... according to a user by the name of munrocket, there seems to be a definition for stage `-1` proposals? > **Stage -1** is actually idea thread in discourse. > Seems that I created topic in a wrong section there. source: https://github.com/tc39/proposals/pull/362#issuecomment-871434628 [03:54:52.0725] the process document (https://tc39.es/process-document/) is silent on the matter and i have personally been curious about this myself since the proposal template also suggests that there is a stage -1 (https://github.com/tc39/template-for-proposals/blob/main/spec.emu) /cc yulia maybe knows? [09:01:50.0782] DerekNonGeneric: "stage -1" is just a conventional way to refer to ideas that aren't actually an official proposal [09:04:12.0117] ljharb, is that the same thing as "spec fiction" then? [09:04:44.0275] spec fiction is something in the spec that no implementation has [09:08:45.0937] "stage -1" is just a convenient way to describe a proposal idea seeking a champion, since without a champion it's not actually a proposal [09:09:18.0891] technically without consensus for stage 1 it's not a proposal [09:09:27.0827] or with consensus for stages 2-4 [09:10:03.0316] that's not true. technically there are no entry requirements for stage 0 [09:10:21.0414] ye i was making a joke about stage 1 being called "Proposal" [09:10:34.0375] but since that technically means EVERYTHING is already a stage 0 proposal, we've always treated it as "it's not stage 0 til a champion has it on an agenda" [09:29:43.0860] > <@devsnek:matrix.org> spec fiction is something in the spec that no implementation has this seems to be a pretty accurate description from what i can tell elsewhere... > times, if browser makers refuse to implement a platform feature, > there's no point having it in the spec; the spec would be fiction. source: https://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/063981.html [09:30:39.0223] thanks much! [09:35:29.0830] /me thinking about how to distill this -1 info into a PR to the stage table in the process document [09:37:51.0609] i do not think it belongs there. [09:37:56.0837] it's just a community convention. [09:38:48.0832] hmm, maybe a small note in the table caption would be enough [09:43:13.0728] even that would give it more officialness than it deserves, i think [09:45:22.0239] if we had that wiki up and running, an entry there would be nice 2021-07-15 [17:27:32.0801] I think for future large changes like class fields it would be nice to split them into multiple commits [17:44:56.0898] it's certainly nicer that way, but it's often a great deal of work [17:45:34.0203] I'd be open to doing it if it's something many people would get a lot of benefit from [17:47:24.0171] i can't speak for anyone else but i would certainly benefit from it [18:18:52.0904] We did a bunch of work to maintain them separately for a while across rebases but it was ultimately merged [18:19:03.0196] It would help to know why anyone would benefit [18:19:37.0800] Engines did not end up slicing up shipping based on the proposal split [18:20:01.0011] oh i don't mean by the individual field types [18:20:21.0401] The state of the language with the different subsets is well-documented; it wasn't clear to me what multiple commits would give us [18:20:23.0016] i mean like, there is a lot of refactoring across various things that happened to enable "class fields" in the general sense [18:21:01.0817] OK, well, it sounds like you're asking for an even more involved factoring then [18:21:05.0617] going over thousands of lines of diff to understand what changed is a very difficult way to figure it out [18:21:19.0392] I dunno, I am happy to answer questions [18:22:33.0268] But basically no existing semantics changed, only new things were added [18:25:02.0436] i'm hearing gus' request as, smaller git commits so that one can choose to look at smaller chunks of conceptual additions at a time. which is definitely a difficult ask, and on class fields in particular would have likely been exceedingly difficult since it was the combining of three repos [18:25:09.0591] * i'm hearing gus' request as, smaller git commits so that one can choose to look at smaller chunks of conceptual additions at a time. which is definitely a difficult ask (but a nice to have), and on class fields in particular would have likely been exceedingly difficult since it was the combining of three repos [18:26:24.0063] yeah for example, moving classes from methods to fields, without adding all the new field kinds, might have been one step, idk [18:26:32.0385] i don't think it matters too much, the past is the past [18:37:56.0842] yeah, to be clear, it would definitely be an after-all-other-work-is-done refactoring [18:38:12.0142] which is pretty common for this type of thing, it's just a bunch of work [18:39:53.0734] in my experience it actually makes it much easier if you start out keeping commits separate, and keep followup changes split into separate commits that point to the ones they should be squashed into later - but it's definitely not a natural way of working with git for many [18:42:44.0507] `git rerere` can help a lot with allowing more commits [18:42:48.0120] for annoying rebases [18:47:14.0652] ljharb: if you do the work in a way where that works, yeah [18:47:25.0715] often there's a big refactor that happens across code touched by many commits, so often you kind of need to come up with the story you're going to tell once you have everything created [18:47:32.0032] which is probably what I would have done for class fields [18:47:37.0828] very fair point [20:24:28.0040] If someone wants to contribute this history refactoring, we can probably find time in Igalia to review it, but we don't plan to spend time writing it ourselves. [20:25:31.0773] we wouldn't change the commits that have landed - it's more something to think about for future large PRs, i think [20:32:49.0652] yeah [20:32:55.0410] also probably would be something the editors would take on [20:35:13.0999] yes i don't think we should rewrite the history [20:35:28.0375] i was just saying it should be something to think about in the future [12:07:46.0422] has anyone ever proposed filter map [16:30:15.0381] wouldn't that be `.flatMap(x => predicate(x) ? [x] : [])`? [16:30:55.0819] * wouldn't that be `.flatMap(x => predicate(x) ? [mapper(x)] : [])`? [16:31:11.0976] * wouldn't that be `.flatMap((...args) => predicate(...args) ? [mapper(...args)] : [])`? 2021-07-16 [19:31:34.0259] sure, but in the same sense as flatMap itself is `.reduce((out, ...args) => out.concat(mapper(...args)), [])` [02:48:30.0542] Hi! I just noticed that `Atomics.multiply()` isn't a thing. Is that because for all other operations you don't need to know whether the type is signed or unsigned but for multiplication you do? [11:19:19.0566] What objects in 262 use option bags? [11:19:31.0739] I am investigating whether error.cause's HasProperty + Get pattern is standard or unusual [11:22:02.0785] 262 itself does not tend to use object bags much, though that's changing. 402 uses them more and just does Get, IIRC [11:22:48.0119] I think we are in generally in favor of just doing Get; I argued for error.cause to be a special case because, unusually, `undefined` is a value one might reasonably want to use [11:23:08.0402] In cases where `undefined` is not an expected value there's no particularly reason to do a Has check first [11:23:23.0387] Hmm [11:23:38.0003] I do not like distinguishing between undefined and not-present in the options bag [11:23:42.0788] As well as on the object itself [11:24:07.0483] I feel like if you really want to split hairs there you should use error.cause === undefined vs. error.cause === null, instead of testing 'cause' in error [11:24:50.0820] The problem is that the error values are generally being handed to you, not a thing you are given yourself: that is, you are writing `catch (e) { throw new Error('message, { cause: e })` without testing the value of `e` [11:25:05.0056] * The problem is that the error values are generally being handed to you, not a thing you are creating yourself: that is, you are writing `catch (e) { throw new Error('message, { cause: e })` without testing the value of `e` [11:26:34.0734] Sure [11:27:16.0364] But I don't understand why that means it's important that `'cause' in new Error('message')` is false whereas `'cause' in new Error('message', { cause: undefined })` is true. [11:28:39.0587] Ah, this was on the assumption that there would not be a `cause` property if you didn't pass the options bag at all [11:28:59.0481] that is, I think it's important that `'cause' in new Error('message', { cause: undefined })`, since you are explicitly asking to create an error with a `cause` [11:29:30.0487] I don't know if I have an opinion about whether `'cause' in new Error('message')` should also be true [11:30:05.0555] but I do think `'cause' in new Error('message')` should match `'cause' in new Error('message', {})` [11:30:14.0951] My opinion is it should also be true [11:30:28.0999] I.e. we should not branch behavior on {} vs. { cause: undefined } [11:31:11.0037] Filed https://github.com/tc39/proposal-error-cause/issues/35 [11:36:31.0599] Mind, it's already stage 3, so I don't know how much appetite there will be for this sort of change [11:56:32.0933] it's also already shipping [11:56:38.0481] well, almost, coming up in chrome 93 [12:01:42.0585] > What objects in 262 use option bags? Temporal uses options bags in almost every method that takes parameters. If we're using them incorrectly or inconsistently, let us know! [12:18:24.0788] My intent was for this to be "implementer feedback" as we work to spec/implement structured clone for it [12:25:25.0477] i was chatting with marja on the V8 team about just this the other day, on whether we should unify option bag handling to be Get for Error cause [12:26:21.0620] my conclusion was that "just a Get" should be the default behavior for option bags, but once in a while a specific use case arises that requires special casing with a Has, like Error cause has with wanting to capture undefined/falsy values, which can be thrown [12:26:54.0854] wait, is that what's being discussed here, i might've skimmed it too fast [12:42:27.0299] Pretty much yeah. I just think we shouldn't distinguish because { cause: undefined } and {} [12:49:58.0552] From a documentation standpoint, does `{ cause: null }` mean "I am filling `cause` but I don't know what the cause was" as opposed to `{ cause: undefined }` which means "I didn't fill in a `cause`"? [12:57:08.0701] are you asking about the status quo or domenic's suggestion? [12:57:33.0130] the status quo is `cause`, if present at all, is honored, since you can `throw undefined;` and maybe you want to capture that in the `cause` [13:27:07.0150] it seems hostile to future options for `new Error(message, {})` to create a `cause` property that would not be present on the result of `new Error(message)` [13:29:52.0290] Got it. TIL that `throw undefined` was a thing. šŸ¤·ā€ā™‚ļø Just when I thought I knew all the weird parts of ECMAScript, it turns out there's always something weirder! [13:39:37.0203] Richard Gibson: I believe the proposal is for `new Error(message)` to also have a `cause` property [13:40:10.0029] per https://github.com/tc39/proposal-error-cause/issues/35 + https://github.com/tc39/proposal-error-cause/issues/36 [14:03:51.0475] Indeed, the idea is that, like everywhere is that I'm aware of in the ES spec ecosystem and web platform, omitting the options object is treated the same as the empty options object which is treated the same as the options object with a bunch of undefineds for each option. [14:06:23.0390] Are there any other options bags for which `undefined` is a value one might end up explicitly supplying as the value of some option? [14:06:31.0616] none in ES including 402, afaik [14:08:53.0429] None in Temporal, AFAIK [16:02:49.0807] WebIDL dictionaries make it impossible to tell the difference 2021-07-17 [19:06:18.0869] is MethodDefinitionEvaluation of AsyncMethod and AsyncGeneratorMethod not supposed to handle private names? [19:06:25.0535] the other two do [19:07:27.0594] oh nvm i missed that its calling DefineMethodProperty instead of DefinePropertyOrThrow [21:57:11.0097] i don't think the default base constructor sets up private fields correctly [21:57:30.0275] i think it is missing a call to InitializeInstanceElements [22:04:46.0856] https://github.com/tc39/ecma262/pull/2462 [22:20:38.0380] yup [22:20:41.0163] all fields, not just private [22:21:06.0141] the fact that the spec differentiates built-in and ecmascript function objects is dumb [22:21:11.0445] I wonder if we can fix that [22:45:11.0122] why do all the new abstract ops take the property before the target object [22:45:14.0923] this is driving me nuts [22:46:00.0330] e.g.? [22:46:14.0070] DefineMethodProperty(propkey, object, ...) [22:46:17.0364] PrivateGet(P, O) [22:46:21.0722] * PrivateGet(P, O) [22:46:22.0167] etc [22:47:03.0605] uhhhh yeah that's super weird [22:47:05.0670] no idea [22:47:26.0241] lol [22:48:03.0077] PRs welcome [22:48:17.0179] I'll do it sometime this weekend if you don't [22:48:33.0776] we'll see where my motivation is [22:53:35.0054] hmmm [22:53:52.0074] MethodDefinitionEvaluation is duplicating calls to SetFunctionName [22:54:03.0224] that fails an assert [22:54:25.0984] ignoring the assert it probably breaks those changes to keep function property ordering consistent [22:55:43.0616] Which two steps do SetFunctionName? [22:55:51.0837] RS itself calls it [22:55:58.0654] and then it calls DefineMethodProperty [22:56:00.0751] which calls it again [22:57:47.0990] ah, just in the generator and async generator cases, yes? [22:59:01.0557] ye [23:02:30.0390] why do generators and async generators have `.prototype`s anyway [23:03:11.0240] cuz they create instances [23:03:26.0513] i think there's a flow chart in the spec :P [23:05:32.0006] oh god I did not realize that that the instances returned by invoking a `function* f() {}` inherit from `f.prototype` [23:05:38.0823] I wonder if anyone is using that for anything [23:05:46.0981] seems like kind of an odd thing to want [23:08:07.0531] oh man private fields have so many early errors this is gonna take forever [23:16:54.0593] fix for the SetFunctionName bug in https://github.com/tc39/ecma262/pull/2463 [23:27:03.0243] nice [23:27:29.0726] why is it a syntax error to do `class { get #f() {} static set #f() {} }` [23:28:09.0790] * why is it a syntax error to do `class { get #f() {} static set #f(v) {} }` [23:29:01.0578] same reason it's a syntax error to do `(class { #f; static #f; })`, presumably [23:29:22.0787] you can make a private name for use on instances or for use on the class, not the same name for both [23:32:01.0112] idk it seems well defined to me [23:32:18.0122] * idk it seems it could be well defined to me [23:33:42.0660] lotta things could be [23:33:58.0861] see previous discussion in at least https://github.com/tc39/proposal-static-class-features/issues/47 [23:34:50.0246] also https://github.com/tc39/proposal-class-fields/issues/256#issuecomment-511213911 [23:48:10.0288] [[PrivateMethods]] and [[Fields]] are not initialized for normal functions [23:48:20.0779] so calling InitializeInstanceFields fails there [23:49:14.0156] maybe OrdinaryFunctionCreate is a good place to set those to new empty lists? [00:05:47.0353] I think I'd prefer to either have [[ConstructorKind]] differentiate between `class`-based ctors and non-, or have InitializeInstanceElements guard on the existence of each slot before reading it [00:06:26.0680] though, I guess we do say in table 33 that all ES functions have those fields [00:08:50.0544] oh, or we could guard on [[IsClassConstructor]] [00:09:19.0581] but given that we do say every function has those two, probably having OrdinaryFunctionCreate initialize them to empty is correct, yeah [00:26:39.0009] i don't think test262 has a test for `'use strict'; delete x` applying recursively, like `'use strict'; delete ((x))` [06:19:03.0259] bakkot: "the fact that the spec differentiates built-in and ecmascript function objects is dumb" Why is that distinction relevant to 2462? [06:41:11.0903] > <@bakkot:matrix.org> oh god I did not realize that that the instances returned by invoking a `function* f() {}` inherit from `f.prototype` This could be useful in the future --- when we have function decorators :) [08:02:52.0822] jmdyck: because InitializeInstanceElements was already invoked by the [[Construct]] method of ES functions, just not the [[Construct]] method of built-in functions [08:18:42.0447] dang this early error for arguments is especially weird [08:23:57.0269] Hm. So for an ordinary built-in constructor, IIE is called from ordinary [[Construct]], but for exotic built-in constructor, exotic [[Construct]] doesn't/can't call IIE, so IIE must be called from the `_behaviour_` supplied to CreateBuiltinFunction? [08:25:50.0531] `class X { #y; foo() { eval('this.#y') } }` [08:25:59.0129] how does the `#y` existing get piped into eval [08:26:28.0024] jmdyck: correct (for base constructors) [08:29:17.0773] devsnek: EvalDeclarationInstantiation step 6/7 [08:29:35.0849] oh i mean [08:29:37.0962] during parsing [08:30:06.0553] the rule is not applied during parsing [08:30:18.0966] wdym [08:30:23.0023] see the last item in https://tc39.es/ecma262/multipage/ecmascript-language-scripts-and-modules.html#sec-scripts-static-semantics-early-errors [08:30:34.0413] man [08:30:52.0748] ok so if eval, turn off private name validation [08:31:08.0497] well, that's how it's specified, yes [08:31:20.0902] same as for validation of `super` and `new.target` [08:31:45.0449] in practice, you'd just find the names before parsing and provide them to the parser [08:32:07.0943] uh [08:32:35.0797] oh you mean like as an optimization to skip having to actually evaluate? [08:33:25.0024] more as a matter of how parsers are implemented; they usually validate as they go, rather than after the fact [08:33:29.0259] but either way works [08:33:37.0342] I guess plausibly they'd keep a list of names that escape [08:34:00.0327] and return that, and do the validation just after parsing by comparing that list to the list of names available in the surrounding context [08:34:11.0294] when i press alt+1, to switch to my first browser tab [08:34:18.0371] bakkot: So then if an implementation chooses to implement a built-in constructor as an ordinary function constructor, it has to 'ignore' the call to IIE in `_behaviour_`, because the ordinary [[Construct]] will call it. [08:34:19.0643] the multipage spec navigates to #sec-ecmascript-function-objects [08:36:08.0429] jmdyck: I suppose, yes [08:36:51.0781] at the very least, if we keep the distinction between the two, we really need to remove the bit that says you can implement built-in functions as ES functions [08:37:06.0895] it's already allowed by the as-if rule, the spec shouldn't have to care [08:37:32.0079] devsnek: it's navigating to your first pin, I think [08:37:34.0373] multipage or not [08:37:57.0448] ah [08:38:01.0784] i didn't realized that was pinned [08:38:13.0254] is that just firefox not capturing its own tab navigation event [08:38:18.0527] presumably [08:38:24.0678] šŸ˜” [08:39:35.0055] so with this set [08:39:39.0584] * so with this eval rule [08:39:47.0953] what handles the private field not existing at runtime [08:40:28.0110] EvalDeclarationInstantiation step 6/7 [08:40:44.0037] bakkot: Isn't it observable whether a built-in is ordinary or exotic? [08:40:52.0369] ah [08:40:59.0329] jmdyck: uhhh I hope not [08:41:12.0950] ok, maybe i'm misremembering [08:41:26.0901] It's entirely possible, there's some weird corners here [08:41:28.0710] but I hope not [08:51:27.0511] i think it used to be [08:51:36.0258] but someone changed that [08:52:00.0988] i recall a presentation discussing if builtins should appear to have been strict or not [08:52:43.0580] if a built-in is ordinary, it's required to be strict [08:54:44.0941] But couldn't an implementation say, it's exotic, but it happens to present like a non-strict ordinary? [08:59:45.0124] What's the intended normative effect of requiring ordinary built-ins to be strict? [09:00:58.0325] under 200 tests failing :O [09:01:16.0160] Presumably we don't have tests for this, because the test doesn't know how the implementation has implemented a given built-in. [09:02:34.0583] are there properties a function can't have in strict mode [09:02:40.0292] like caller or callee or something weird like that [09:09:50.0582] Annex C says "An implementation may not extend, beyond that defined in this specification, the meanings within strict functions of properties named "caller" or "arguments" of function instances." [09:10:31.0689] yeah, but "Built-in functions ... also must not be created with such own properties" [09:10:50.0885] IIRC the strictness thing was to do with whether `this` was undefined or the global [09:11:07.0874] I will try to track it down [09:14:27.0692] It looks like the sentence "Built-in functions that are ECMAScript function objects must be strict..." was added in wd20 of ES6. [09:15:42.0368] (Sept/Oct 2013) [09:19:45.0947] I am having no lucking finding it [09:19:50.0912] but the `this` thing is at least plausible [09:20:18.0220] a lot of builtins operate on their `this`, and it makes sense to say that if you pull those off their containing object and invoke them directly they should not be operating on the global [09:22:21.0485] The change-notes for rev 20 say "Elaborated in 9.3 that built-in functions can be implemented as either ECMAScript functions or as implementation defined exotic functions." but they don't mention the strictness thing. It might be in one of the many bugs that rev20 fixed. [09:23:45.0884] That's... a familiar topic [09:28:25.0307] I presented on Feb 2020 about to make all implementation defined functions in strict mode [09:30:00.0560] For what normative effect? [09:30:28.0338] No progress since then. Maybe I should open a PR [09:30:41.0747] https://github.com/tc39/notes/blob/master/meetings/2020-02/february-5.md#legacy-reflection-features-for-functions-in-javascript-for-stage-1 [09:30:54.0215] No, I mean, what would have been the normative effect? [09:35:19.0586] Back to time that was presented, Chakra (Classic edge) leaks native function (according to spec, strict function are not allowed to be leaked) in loose mode. Is that a normative effect? [10:42:10.0794] What does "leak" mean? [10:59:33.0461] In this context, I'm pretty sure it means "appear as the `.caller` of a sloppy function" [10:59:49.0252] as in `function f(){ console.log(f.caller); } function g(){ f(); } g()` [11:00:10.0104] note the change if you put `'use strict'` in `g` [11:01:20.0521] see the third slide in https://github.com/tc39/agendas/blob/master/2020/02_talk_codiy-dot-caller.pdf [11:11:15.0646] am i crazy or are class field tests like 1/10th of all test262 tests [11:32:24.0816] Just wait until Temporal lands. 2700 tests and lots more to come. [11:56:17.0518] i think class fields has around 16000 2021-07-18 [21:15:18.0516] is ContainsArguments missing AsyncGenerator stuff [21:22:48.0928] devsnek: looks like, yup [21:28:49.0829] super is allowed in fields even without ClassHeritage? [21:32:09.0774] hm i guess its allowed in normal methods too [21:32:10.0527] weird [21:33:57.0509] even in regular objects, yeah [21:34:03.0310] `({ __proto__: { x: 0 }, m(){ return super.x; } }).m()` returns 0 [21:34:30.0878] this language is quite odd [22:04:48.0920] hmm there are a few DefinePropertyOrThrow's missing either a `!` or a `?` in the various InstantiateFooFunctionExpression RS [22:25:53.0184] > <@bakkot:matrix.org> `({ __proto__: { x: 0 }, m(){ return super.x; } }).m()` returns 0 Why super is valid in that context? [22:27:05.0303] devsnek: speaking very pedantically it's not required there; it happens that it doesn't throw, and you don't need the completion record, so it is not incorrect to just do the step and ignore the result rather than doing the step and asserting that the result is not abrupt [22:27:53.0172] would that be lawful evil or chaotic evil [22:32:07.0922] Jack Works: modulo some details about HomeObject, `super.x` mostly just means "access `.x` but on the prototype"; regular objects have prototypes too, so why shouldn't it be valid? [01:36:21.0633] Oh I thought super is only valid in class body [03:15:26.0596] Jack Works: Many people also think `this` in static method is invalid :P [09:22:15.0169] only 8 more failing tests :O [09:44:00.0157] solid 96% coverage of test262 now 2021-07-19 [20:00:24.0391] Can someone confirm whether the change in https://github.com/mdn/content/pull/6255/files is correct per-spec? [20:41:58.0803] sideshowbarker: IMO, it seems this PR just use slight different words but don't really have any real difference with the old sentences. [21:12:32.0825] sideshowbarker: Oh, I think I missed the interesting thing it the PR, chrome/ff inconsistency :) It seems V8 don't keep order of a, b as the original order in the array when call compareFn(a, b) ... Spec seems say nothing about that. [21:26:38.0789] sideshowbarker: that's correct (as of https://github.com/tc39/ecma262/pull/1340) only for consistent comparison functions, which several of the samples discussed in that thread are not. The spec makes no guarantees about the sort order when the comparison function is not consistent [21:28:18.0475] That said it's definitely an improvement: for consistent comparison functions, `compareFn(a, b) < 0` means "put a before b, regardless of where they were originally", not "leave them in their original order" [23:13:32.0325] HE Shi-Jun: Thanks for commenting over there [23:15:14.0455] bakkot: maybe I can push a commit to that branch with trims the change down to that [23:15:56.0020] bakkot: in the meantime, a comment from over there would be welcome [23:16:22.0807] I wish the spec itself has some more explicit language for developers on this [23:17:06.0551] I am very happy with the spec sections that now have the non-normative green notes sections with explanatory text [01:25:24.0437] bakkot: thanks for adding a comment on that MDN PR [01:52:18.0010] does the change in https://github.com/mdn/content/pull/7027/files seem like a reasonable way to work around the issue described in https://github.com/mdn/content/issues/7026? [01:53:34.0861] hmm, I guess this isnā€™t specifically a JavaScript issue ā€“ so will re-ask on #whatwg:matrix.org [03:29:47.0987] https://github.com/mdn/content/issues/7034 is a good first issue for anybody interested in contributing to MDN 2021-07-20 [19:28:02.0953] why does test262-harness think engine262 fails tests that it doesn't fail [19:29:16.0750] it looks like its parsing the stderr wrong or something [19:29:23.0463] but eshost-cli shows it correctly 2021-07-21 [23:24:51.0875] https://github.com/mdn/content/issues/7106 [23:25:27.0741] where does the `errors` property of `AggregateError` instances come from? [23:30:20.0182] see also https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/any#rejection [23:31:15.0240] > If all of the passed-in promises reject, `Promise.any` asynchronously rejects with an {{JSxRef("AggregateError")}} object, which extends {{JSxRef("Error")}}, and contains an `errors` property with an array of rejection values. [23:32:14.0169] `errors` is not part of the prototype of `AggregateError`, so I donā€™t understand where itā€™s coming from [23:35:36.0489] looking at the spec at https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-aggregate-error-objects, I also donā€™t see any mention of `errors` [00:34:56.0228] > <@sideshowbarker:mozilla.org> `errors` is not part of the prototype of `AggregateError`, so I donā€™t understand where itā€™s coming from https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-aggregate-error Step 5 > `Perform ! DefinePropertyOrThrow(O, "errors", PropertyDescriptor { [[Configurable]]: true, [[Enumerable]]: false, [[Writable]]: true, [[Value]]: ! CreateArrayFromList(errorsList) }).` [01:35:26.0853] > <@aclaymore:matrix.org> https://tc39.es/ecma262/multipage/fundamental-objects.html#sec-aggregate-error Step 5 > > `Perform ! DefinePropertyOrThrow(O, "errors", PropertyDescriptor { [[Configurable]]: true, [[Enumerable]]: false, [[Writable]]: true, [[Value]]: ! CreateArrayFromList(errorsList) }).` dā€™oh ā€” thanks much, I donā€™t know how I overlooked that beforeā€¦ [12:11:46.0268] general question: what's the best supported emacs TS mode? 2021-07-22 2021-07-23 2021-07-24 2021-07-25 2021-07-26 2021-07-27 [09:38:40.0121] bakkot: re https://github.com/WICG/app-history/issues/40#issuecomment-780765435 how is do/async do going? 2021-07-28 [09:41:21.0695] If somebody has energy to add a comment over at https://github.com/mdn/content/pull/7386, I would appreciate it [09:44:31.0655] Domenic: current status is that I'm gathering feedback on usability. I need to follow up on that, so thanks for the ping. [09:45:03.0444] (people had plausible usability concerns about async do also, which is why I'm not just going forward with it) [10:05:52.0865] K, just wondering at what point we should make all web platform functions that take promises take functions that return promises as well 2021-07-29 [16:51:22.0922] *cough* https://twitter.com/gesa/status/1420894121317724163 [16:51:41.0961] https://twitter.com/gesa/status/1420894145552420865 2021-07-30 [16:41:05.0153] Domenic: Give at least a little while longer, we're circling towards `do` (and thus `async do`) relatively productively. [16:41:33.0626] Ah bakkot already said that, tho in a more pessimistic fashion [16:41:34.0914] anyway [16:42:36.0686] In ecmarkup, what does `type="abstract operation"` do, and what is its relationship with the `aoid` attribute? [16:45:55.0462] Some clauses are annotated, but I canā€™t find any examples where both occur. I had thought that the point of `aoid` was to mark the clause where an abstract operation gets defined with its name, so that the name could automatically get cross-referencedā€”but then I donā€™t know where `type="abstract operation "` comes in. [16:46:06.0994] * Some clauses are annotated with one or the other, but I canā€™t find any examples where both occur. I had thought that the point of `aoid` was to mark the clause where an abstract operation gets defined with its name, so that the name could automatically get cross-referencedā€”but then I donā€™t know where `type="abstract operation "` comes in. [16:46:29.0807] * Some clauses are annotated with one or the other, but I canā€™t find any examples where both occur. I had thought that the point of `aoid` was to mark the clause where an abstract operation gets defined with its name, so that the name could automatically get cross-referencedā€”but then I donā€™t know where `type="abstract operation"` comes in. [16:53:12.0009] Ah, I see, so `type="abstract operation"` automatically generates a paragraph about its parametersā€¦ [16:53:23.0918] * Ah, I see, so `type="abstract operation"` seems to automatically generate a paragraph about its parametersā€¦ 2021-07-31 [18:42:20.0211] jschoi: right, that's a new change as of https://github.com/tc39/ecma262/pull/545. there's also `type="concrete method"` and a couple others. the idea is that we are trying to have more structured data in ecmarkup, which we use to derive the boilerplate description and also the AOID [09:12:46.0539] Hopefully one day bringing us closer to being able to click on [[Get]] and get a link to all instances of it... [09:17:19.0324] [[Get]] is an interesting example, because it's used in 3 different ways: an internal method, a field in some records, and an accessor property attribute. [09:17:46.0636] Turn spec into a real language and analyze it with language service šŸ‘€ [09:19:16.0039] turning the spec into a real language is roughly what https://github.com/jmdyck/ecmaspeak-py is doing. [09:19:46.0143] Making an LSP module isn't on my to-do list, but it's a possibility. [09:20:55.0783] * "turning the spec into a real language" is roughly what https://github.com/jmdyck/ecmaspeak-py is doing. [09:21:03.0861] The spec website is having some functionalities of LS like finding references or highlights related variables