2022-02-01 [22:51:09.0734] jmdyck: FYI, I made further changes based on review comments from other MDN writers. If/when you have time to take a look at the current text, that’d be much welcome. [05:46:18.0256] sideshowbarker: I think the "For example" para has a problem where it says `and you change that to {"list":["oil","flour","sugar"]}`, because it depends on how one imagines accomplishing that change. I read it as (say) `copy[1] = {"list": ...}`, but I'm guessing you meant it as `copy[1].list = ["oil"...]`. The first isn't 'visible' to the original, the second is. [06:57:18.0971] > <@jmdyck:matrix.org> sideshowbarker: I think the "For example" para has a problem where it says `and you change that to {"list":["oil","flour","sugar"]}`, because it depends on how one imagines accomplishing that change. I read it as (say) `copy[1] = {"list": ...}`, but I'm guessing you meant it as `copy[1].list = ["oil"...]`. The first isn't 'visible' to the original, the second is. Ah yes, thanks, I'll fix that [09:04:02.0766] jmdyck: thanks again — now updated [10:52:52.0346] this is some pretty wild spam https://gc.gy/111446560.png [10:53:49.0706] looks like the body text and username are scraped from the tc39 discourse [10:57:34.0492] oh hey, node shipped fetch! (experimentally) [14:33:06.0306] > <@devsnek:matrix.org> this is some pretty wild spam https://gc.gy/111446560.png looks like spammers are starting to use gpt lol [14:33:46.0644] either that or kevin's bot has become sentient and we all need to be very worried 2022-02-04 [17:48:59.0928] looking at https://github.com/mdn/content/issues/12679 [17:49:58.0563] comments in that issue or here would be welcome [17:50:27.0801] in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/block#block_scoping_rules_with_let_const_or_function_declaration_in_strict_mode MDN says: > In strict mode, starting with ES2015, functions inside blocks are scoped to that block. Prior to ES2015, block-level functions were forbidden in strict mode. [17:50:55.0970] I am looking for where in the spec such a requirement is actually stated [17:51:32.0730] I don’t seem to find it in the Appendix C summary https://tc39.es/ecma262/multipage/strict-mode-of-ecmascript.html [17:52:03.0131] * I don’t seem to find it in the Appendix C summary https://tc39.es/ecma262/multipage/strict-mode-of-ecmascript.html [17:54:46.0435] See https://tc39.es/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics [17:58:55.0225] So "Prior to ES2015, block-level functions were forbidden in strict mode." is technically correct, but misleading, because they were also forbidden in non-strict mode. (Forbidden by spec, not by implementation, that is.) [18:08:12.0933] ah, and this is the part that implements the block scoping (3b) [18:20:50.0595] Re not finding it in Annex C: It looks like Annex C doesn't mention differences between strict and non-strict that only arise due to Annex B stuff. [13:04:25.0267] New Babel version with decorators that conform to the latest version of the proposal came out a few days ago https://babeljs.io/blog/2022/02/02/7.17.0#decorators-14004httpsgithubcombabelbabelpull14004-13681httpsgithubcombabelbabelpull13681 , but there has been no news about it on twitter or even Decorator proposal repo! Next step according to Decorators proposal's standardization plan is to collect feedback on the transpiler implementation, but we can't do it if no-one tests it out. (Unless no comments / testers is treated as no objections and it thus proceeds forward). Drum up the social media and other channels! Make people excited about decorators! 2022-02-05 [22:24:44.0559] In case anyone has thoughts: https://stackoverflow.com/questions/70973827/is-there-a-mistake-in-ecmascript-spec-relating-to-unicode-code-points [22:33:09.0177] i think the spec is saying exactly what you do [22:33:20.0585] > When a stream of code points is to be parsed as an ECMAScript Script or Module, it is first converted to a stream of input elements by repeated application of the lexical grammar; [22:34:56.0857] i think this is the section of the spec that defines what it means to actually "parse sourceText using goalSymbol" [22:42:11.0351] yup, that's my reading too 2022-02-06 [09:10:23.0805] is it "allowed" for an implementation to set the value of [[ImportMeta]] to some arbitrary value before the logic of loading import.meta runs, effectively short circuiting it? [09:10:45.0041] i should say this question isn't so much about import.meta specifically as it is about the "short circuiting" of intended semantics 2022-02-07 [13:45:36.0061] Notes for the post-plenary ad-hoc dataflow meeting have been published at https://github.com/tc39/incubator-agendas/blob/master/notes/2022/01-27.md. [14:37:05.0490] thank you very much for taking notes and publishing them! 2022-02-10 [23:13:26.0611] does anyone know why is propertyIsEnumerable [23:13:31.0173] like, why does that... exist [23:14:08.0561] Object.prototype has like a dozen properties total and one of them is `propertyIsEnumerable`, which I have never in my life wanted [03:53:28.0414] MDN users are reporting that tc39.es is 404'ing. https://github.com/mdn/content/issues/12889. Did anything change? (all of the JS docs link to this host) [03:54:07.0127] Florian Scholz: Chairs have already been notified - hopefully it'll be taken care of soon :-) [03:55:12.0012] Luca Casonato: wonderful, bedankt! [05:17:52.0960] @bakkot: propertyIsEnumerable was added in ES3, if that helps. [05:18:50.0618] > <@floscholz:mozilla.org> MDN users are reporting that tc39.es is 404'ing. https://github.com/mdn/content/issues/12889. Did anything change? (all of the JS docs link to this host) it's fixed [07:27:34.0263] bakkot: I’ve definitely used it. Before es5, it was the only way to differentiate enumerability, of the length property in particular. 2022-02-11 [00:52:12.0479] comments welcome at https://github.com/mdn/content/issues/12908 or here > It is not clear what `return` in a `forEach` iteration is supposed to do. [00:52:46.0009] * comments welcome at https://github.com/mdn/content/issues/12908 or here > It is not clear what `return` in a `forEach` iteration is supposed to do. [01:00:12.0697] isn't that expected? [01:00:43.0917] returning skips the rest of the callback, but not subsequent iterations, because they're different runs of the callback [01:01:08.0886] the issue only comes when porting code that uses a for loop to code using `forEach` [01:08:25.0928] I suspect what they're asking for is for the article to point out you cannot break out of the loop. [04:18:02.0466] There is already a section for this that says: "There is no way to stop or break a forEach() loop other than by throwing an exception" https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach#sect2 [04:18:33.0635] maybe it could be even more explicit? [04:46:27.0920] Good point, dunno then. [05:08:44.0074] OK, thanks all — yeah, seems like the OP just had the expectation that the `return` would break out of the `forEach()`. So I guess I’ll add something to the _“There is no way to stop or break a `forEach()` loop other than by throwing an exception”_ note explicitly saying that a `return` will not break out of the `forEach()` but will instead just return from the current call to the callback function, and the continue the loop. [06:17:09.0504] the easy workaround is to use `.every()` and `return true` to continue and `return false` to break [06:17:39.0553] but feels weird since it’s not a function supposed to be side effectful [06:18:05.0855] * the easy workaround is to use `every` and `return true` to continue and `return false` to break [06:18:19.0373] * the easy workaround is to use `.every()` and `return true` to continue and `return false` to break [08:19:04.0857] Check for my own sanity: The fact that https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence puts `? :` on a precedence level tighter than `=` and `yield` is incorrect, right? [08:19:26.0461] Because https://tc39.es/ecma262/#prod-AssignmentExpression says AssignmentExpression : ConditionalExpression and ConditionalExpression : ShortCircuitExpression `?` AssignmentExpression `:` AssignmentExpression. [08:20:24.0166] (I already fixed one error in this table with `??` last year, so I’m not surprised there’s still other errors.) [08:21:38.0346] it's not really meaningful to talk about precedence for a ternary as a whole [08:21:39.0736] but `yield a ? b : c` is `yield (a ? b : c)` and `x = a ? b : c` is `x = (a ? b : c)` [08:21:51.0977] * but `yield a ? b : c` is `yield (a ? b : c)` and `x = a ? b : c` is `x = (a ? b : c)` [08:22:13.0050] so to the extent there is precedence at all, I think it's correct to say that `yield` binds less tightly than `? :` [08:26:48.0238] Point taken. This is mostly a result of the weird interactions between ternary and unary/binary operators… [08:32:18.0764] well, and assignment [08:32:49.0742] `yield` is less weird because `yield a` is always `yield a` in any of the three positions [08:33:24.0756] but assignment is weird because `a = b ? c : d` parses as assignment-containing-ternary whereas `a ? b : c = d` parses as ternary-containing-assignment [08:33:36.0361] Yeah, and assignment’s weird asymmetry too. [08:34:12.0777] Come to think of it, I still want to add `=>` to this table, since it is pretty much analogous to `=`… [08:35:19.0848] `=` and `=>` are both more like…prefix unary operators on their RHS. (With possible evaluation on any default expressions in their LHS afterwards.) [08:38:07.0066] (All of this weirdness is also why we are banning mixing any of these within `|>` pipe expressions without parentheses.) [08:38:31.0567] * `=` and `=>` are both more like…prefix unary operators on their RHS. (With possible evaluation on any default expressions in their LHS afterwards.) [09:44:44.0659] Still think that forEach should be extended to pass the callback a fourth argument that's a "halt token", which stops execution if you return it. Then the four callback arguments will be Element, Index, Collection, Halt, or EICH [10:25:18.0114] Or just don't use forEach... for-of is just way better IMO. [10:28:14.0577] https://ericlippert.com/2009/05/18/foreach-vs-foreach/ [10:41:54.0714] Yeah, but Tab has a point: we would get an EICH abbreviation in the language. The next step would be to somehow add BRENDAN somewhere. [10:43:59.0926] right, that's the whole point. not worth doing it otherwise [11:29:42.0033] Given that `1 ? x = 2 : 3` groups as `1 ? (x = 2) : 3` and that `1 ? x => 2 : 3` groups as `1 ? (x => 2) : 3`, is it fair to say that `? :` is acting “looser” than `=` or `=>` here? [11:29:47.0852] > <@bakkot:matrix.org> but `yield a ? b : c` is `yield (a ? b : c)` and `x = a ? b : c` is `x = (a ? b : c)` * Given that `1 ? x = 2 : 3` groups as `1 ? (x = 2) : 3` and that `1 ? x => 2 : 3` groups as `1 ? (x => 2) : 3`, is it fair to say that `? :` is acting “looser” than `=` or `=>` here? [11:33:43.0857] I wouldn't describe it that way personally, since that it is also true that `a => b ? c : d` groups as `a => (b ? c : d)` [11:34:04.0566] you can't really say one is strictly looser than the other [11:34:39.0848] Yeah. The whole concept of “precedence” breaks down at this level…I’m not sure how to explain where `|>` (which has similar “precedence” as these) fits in with them in laypersons’ terms (let alone explaining how `yield`, `=`, `=>`, and `? :` interact in such terms). [11:34:52.0405] I don't think laypeople think in terms of precedence [11:35:11.0645] just give examples of how various things would be grouped like we've been doing here [11:35:16.0911] it's by far the clearest way to explain [11:37:04.0028] Well, one thing I know is that laypeople have been referring to that MDN precedence table, and that the table has been confusing laypeople about `? :`, `=`, and `yield`. [11:37:26.0865] So I wonder if we shouldn’t put `? :`, `=`, `yield`, and `=>` all on one “precedence level” and just say, “These don’t really have more or less ’precedence’ than one another; they have special rules; see these examples.” [11:37:34.0700] * So I wonder if we shouldn’t put `? :`, `=`, `yield`, and `=>` all on one “precedence level” and just say, “These don’t really have more or less ’precedence’ than one another; they have special rules.” [11:38:08.0770] * Well, one thing I know is that laypeople have been referring to that MDN precedence table, and that the table has been confusing laypeople about `? :`, `=`, and `yield`. [11:38:25.0624] * So I wonder if we shouldn’t put `? :`, `=`, `yield`, and `=>` all on one “precedence level” and just say, “These don’t really have more or less ’precedence’ than one another; they have special rules; see these examples.” [12:45:42.0100] jschoi: Re question in Delegates room: you can say "the first AssignmentExpression" and "the second AssignmentExpression" [12:48:00.0980] See e.g. https://tc39.es/ecma262/#sec-runtime-semantics-forloopevaluation where it has to differentiate between the various |Expression|s [13:48:36.0559] Sorry, wrong room! 2022-02-12 [18:09:10.0108] > Is there anything different about lists than sequences which makes it better on lists? What’s the distinction between a list and sequence? Is that distinction clear in most languages, or is it more distinct in C#? [18:09:18.0357] > <@domenicdenicola:matrix.org> https://ericlippert.com/2009/05/18/foreach-vs-foreach/ * > Is there anything different about lists than sequences which makes it better on lists? What’s the distinction between a list and sequence? Is that distinction clear in most languages, or is it more distinct in C#? [18:15:06.0289] > <@domenicdenicola:matrix.org> Or just don't use forEach... for-of is just way better IMO. Yeah I think I probably should make a further update to the Examples section of the MDN `Array` doc in my https://github.com/mdn/content/pull/12781 PR to state that. [18:55:52.0711] In js, a list and a sequence are both just a conceptual ordered list of things; usually represented by an array [18:56:17.0570] as for forEach vs for-of, opinions vary widely on that :-) 2022-02-14 [17:34:26.0444] hi again! State of JS survey guy here :) I just wanted to say I'm putting the finishing touches to this year's report, it should be available very soon [17:34:50.0698] maybe once it's out we can do the call we discussed so you guys can give me some feedback for next year's edition? [17:58:17.0229] here's an early preview (still working on the "JS" logo, that's why it says "CSS"): https://2021.stateofjs.com/en-US/ [17:58:20.0209] password: `js` [00:34:02.0201] looking at https://github.com/mdn/content/issues/12643 [00:35:36.0340] in the code in that issue description, I’d have expected `const newCopy = { ...foundBananas }` does a shallow copy  — and so, that `newCopy.quantity = 30` would also change the `quantity` property in `foundBananas` [00:36:20.0050] …but it doesn’t change `foundBananas`; `foundBananas.quantity` is still `0`. Why? [00:37:23.0024] * in the code in that issue description, I’d have expected `const newCopy = { ...foundBananas }` does a shallow copy  — and so, that `newCopy.quantity = 30` would also change the `quantity` property in `foundBananas` [00:41:34.0145] Returning a copy would be pretty useless in most cases when I think about it. That way you wouldn't ever be able to use find to modify an entry in the original array. [00:44:24.0140] > <@sideshowbarker:mozilla.org> in the code in that issue description, I’d have expected `const newCopy = { ...foundBananas }` does a shallow copy  — and so, that `newCopy.quantity = 30` would also change the `quantity` property in `foundBananas` `const newCopy = { ...foundBananas }` indeed does a shallow copy. The code is practically the same as `const newCopy = { name: foundBananas.name, quantity: foundBananas.quantity, }`. You can see in the latter case where changing the value would not change the original. [00:45:32.0139] * For original bug, returning a copy would be pretty useless for `find` in most cases when I think about it. That way you wouldn't ever be able to use find to modify an entry in the original array. [00:51:19.0195] so for being daft, but I guess I still don’t understand how using spread syntax here is different from `Object.assign()` [00:51:33.0917] clearly I’m just looking at it wrong [00:53:23.0612] > <@sideshowbarker:mozilla.org> so for being daft, but I guess I still don’t understand how using spread syntax here is different from `Object.assign()` Is it different? [00:54:34.0217] ```js const newCopy = Object.assign(foundBananas); newCopy.quantity = 30; console.log(foundBananas.quantity); // 30 ``` [00:58:57.0675] For JS help, there are better places. [01:00:52.0508] (The deleted conversation was just generic JS help) [02:04:36.0670] * (The deleted conversation was just fixing a misunderstanding on JS behavior) [02:40:37.0029] > <@sideshowbarker:mozilla.org> What’s the distinction between a list and sequence? Is that distinction clear in most languages, or is it more distinct in C#? think of a Sequence as any abstract iterable, while a List has a defined memory layout [03:14:36.0767] That would seem to suggest that a List is a subclass of an (abstract) Sequence — but the _“Is there anything different about lists than sequences which makes it better on lists?”_ language that Eric Lippert uses in https://ericlippert.com/2009/05/18/foreach-vs-foreach/ seems to imply that they’re somehow two more-distinct things (in C#, I guess). But maybe I’m reading too much into it. [03:17:41.0275] When I see “sequence” for me what comes to mind is C++, where there’s no Sequence as such in the language — nothing formally called that — but just the term “sequence” is used in C++ documentation to distinguish the `vector`/`array`/`list` containers from the associative containers. [03:19:30.0657] And whereas in documentation for Java and Python (the main other languages I’m familiar with), there’s no set of things in the language that are typically referred to as “sequence” things. [03:19:40.0764] * And whereas in documentation for Java and Python (the main other languages I’m familiar with), there’s no set of things in the language that are typically referred to as “sequence” things. [03:20:43.0252] Anyway, I suppose this is probably not very on-topic here. If so, apologies for the noise. [05:11:42.0013] is there any discussion about weak import? 🤔 [05:18:07.0098] > <@jackworks:matrix.org> is there any discussion about weak import? 🤔 * --await-- import(); ? [05:20:09.0946] sideshowbarker: The documentation for Python does have things referred to as "sequences": https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy [15:03:02.0277] Jack Works: what would be the use case [15:03:55.0759] context: https://github.com/tc39/proposal-resizablearraybuffer/issues/91 [15:04:03.0343] i think of it like `.slice()` (which would be the first one, i guess?) [15:04:15.0746] * i think of it like `.slice()` (which would be the first one, i guess?) [15:04:51.0488] but that also means that i'd expect the return value to be the same kind of thing as the receiver - meaning, if the receiver is length-tracking i'd expect the subarray to be [15:05:01.0973] `.slice()` always creates a new TA entirely, with its own buffer [15:05:09.0569] `.subarray()` does not [15:05:22.0137] sure, i know it's a bit different :-) but i think of it in similar terms [15:05:22.0965] so the question doesn't apply to `.slice()` [15:05:54.0671] well, i mean the similarity doesn't make sense to me, since the "length tracking or not" really only makes sense if it's the same underlying buffer [15:05:58.0143] i'd still expect the newly created thing to be "the same" as the original one as far as various characteristics go [15:06:40.0301] i def see how it's not a clear answer - not sure if the poll helps answer it tho. [15:07:21.0852] "the same" is too imprecise to give me a sense here [15:07:59.0650] in the first option, if `ta` is length-tracking, *i* would not expect `ta.subarray(begin, ta.length - 1)` to create a length-tracking TA [15:08:03.0997] because i am explicitly asking for a subarray with a begin and an end, i.e. a fixed-length [15:10:44.0800] so the question is, if i omit the second `end` argument, do you think of it like if you gave an explicit `end` argument of the current last index of the TA (i.e. fixed-length), or do you think of it like you're creating a new TA of the same underlying buffer with no set end (i.e. length-tracking)? [15:11:28.0713] since resizable TAs don't exist today, the two views are semantically equivalent today [15:12:01.0168] * so the question is, if i omit the second `end` argument, do you think of it like if you gave an explicit `end` argument of the current last index of the TA (i.e. fixed-length), or do you think of it like you're creating a new TA of the same underlying buffer with no set end (i.e. length-tracking)? [15:13:45.0772] google isn't helping me - what does "length-tracking" mean? [15:14:43.0796] see here: https://github.com/tc39/proposal-resizablearraybuffer#modifications-to-typedarray [15:17:16.0839] aha, so if the subarray is length-tracking, it means it inherits the "indefinite end" quality of the parent buffer? [15:18:55.0701] of the parent TA, not the parent buffer, but otherwise yep [15:19:23.0530] "resizable or not" is a quality of the parent buffer, and "indefinite end" is a quality of the original TA [15:23:05.0371] Right, right. [15:23:11.0186] ljharb: as for the slice question, the consensus currently is that `slice()` always create a new, non-resizable/non-growable ArrayBuffer [15:23:48.0863] so if you maximize for consistency with that, then i think you get that `subarray()` does not inherit the length-tracking-ness [15:24:34.0670] I think I like the latter behavior, since subarray is a view on the parent TA's buffer rather than a new buffer. [15:25:28.0304] it is technically possible that we change `slice(begin)` to also make a new resizable buffer, but i think that's strictly undesirable [15:26:45.0184] since most of the time you're probably taking slices for, well, a smaller portion of the buffer. if you make a new resizable buffer, you end up wasting virtual memory for no reason for the common use case [15:26:49.0365] TabAtkins: yeah, i can see that [15:27:32.0909] ("latter" meaning "the second poll option", not to any pair of behaviors mentioned hence) 2022-02-16 [16:59:14.0110] wasm's GC proposal is going to stage 2! 🎉 https://twitter.com/tlively52/status/1493681050693738501 [16:59:32.0151] soon my i will be able to realize my dream of implementing javascript in wasm [17:55:16.0986] you think he's joking but he's not [17:55:18.0864] he's really not [17:56:06.0666] ... and I will probably help him do it [18:14:23.0497] "because it is there", or does JS-in-WASM have some practical utility? [18:49:24.0693] well, we're already doing js-in-js, in production [18:50:06.0487] * well, we already have js-in-js, may as well also have js-in-wasm [18:50:20.0574] * well, we (= my team) already have js-in-js, may as well also have js-in-wasm [23:03:20.0770] bakkot: then i'm looking forward to your support to the js structs proposal, as the JS reflection of wasmgc structs :) 2022-02-17 [17:57:45.0052] https://2021.stateofjs.com/en-US/features [17:57:50.0888] Optional Chaining is taking over the web [00:15:47.0774] > <@jmdyck:matrix.org> "because it is there", or does JS-in-WASM have some practical utility? might be easier to sandbox 2022-02-18 [17:00:26.0436] Shouldn't the latest meeting notes be out by now? [08:41:34.0451] jmdyck: https://github.com/tc39/notes/pull/185 2022-02-21 [18:35:33.0406] what happens if you replace direct calls to eval with a single string argument with the equiv code inside that string argument [20:50:07.0314] Does strict mode also applies? Or, any different between import related stuff? [09:15:46.0788] devsnek: if the code in eval worked, I’d expect it to work the same without the eval. The reverse might not be true. [09:21:19.0797] yeah I assume there's probably some small difference with like variable declarations or smth but idk [09:34:32.0482] strict mode `var` declarations aren't hoisted out of the eval, though sloppy mode `var` declarations are. [09:34:56.0842] also `var` declarations from `eval` can be `delete`'d, unlike normal `var` declarations [09:34:59.0967] otherwise pretty similar 2022-02-23 [08:41:27.0397] const f = () => class T { [do { return () => T }] = 0 } [08:41:31.0278] TDZ? [08:49:46.0617] I'd expect tdz [08:50:23.0542] Because the binding is initialized after evaluating computed keys, and that evaluation doesn't complete normally in this example [08:56:26.0571] tried with yield. it's TDZ 2022-02-24 [20:39:16.0152] Is the change in https://github.com/mdn/content/pull/13229/files correct? Specifically, does `handler.defineProperty()` intercept `Object.prototype.__defineGetter__` and `Object.prototype.__defineSetter__`? [20:50:08.0264] Barring exceptions, `__defineGetter__` and `__defineSetter__` invoke `DefinePropertyOrThrow`, which invokes `[[DefineOwnProperty]]`, which in a proxy is handled by the `defineProperty` method, so I'd say yes. [20:52:54.0523] Mind you, there are a lot of things that invoke DefinePropertyOrThrow, so it might be a long list if you want to be complete. [21:05:25.0198] jmdyck: I guess for now I won’t worry about trying to make sure it’s an exhaustive list, but will instead just accept and merge that change. [03:04:26.0567] About the decorators proposal: I think there was a requirement introduced that if a field is decorated, its type is not changed -- which resulted in the requirement for the accessor keyword. Does anyone have a reference to that discussion? [08:22:03.0567] yulia: by type you mean "class element kind"? [08:22:34.0359] i didn't attend the discussions that hashed this out, but the requirement was introduced in response to V8 feedback [08:24:05.0024] https://github.com/tc39/proposal-decorators/issues/302, and sathya also had a doc on the previous-previous iteration: https://docs.google.com/document/d/101VnCaQaheEwSXQ_-eSAKpkutnAbDjS9T5TS2gF5zLQ/edit [08:24:16.0638] though the latter doc might be slightly out of date [09:14:09.0506] great, thank you shu [09:15:04.0887] One more question, this time for rbuckton -- the metadata part of that proposal, is it critical that it is within the same proposal or could we split it out the way that you had it initially? If there are documents I can look at for that you can just point me to them... [09:22:43.0354] i've had similar standing concerns about the metadata part, yes [09:31:09.0262] Some mechanism for metadata is necessary for patterns such as Dependency Injection. Without a standardized approach to metadata there would be no consistent mechanism with which to store and access this information, unless the community gravitates to a single implementation. Previously, the community has gravitated towards `reflect-metadata`, however that approach currently depends on mutating the `Reflect` global to add features that would likely not be supported by TC39 since they do not directly correlate to `Proxy` handler operations. Having a standard mechanism for defining metadata is extremely useful for tooling, such as TypeScript's `--emitDecoratorMetadata` feature. That feature depends on a consistent mechanism for defining metadata, but currently leverages the non-standard `Reflect.metadata` method that is provided by the `reflect-metadata` package. [10:03:27.0290] if metadata means ts will give us ts type annotations as runtime information that would be cool [10:03:38.0509] if its just limited to decorators tho that would be sad [12:26:29.0886] when using the new structured headers for abstract operations, is it OK to give the type of a parameter as something like `foo: a Temporal.PlainDate instance` or should we stick with the wording that I'd have previously put in an assertion (`foo: an Object with an [[InitializedTemporalDate]] internal slot`)? [12:27:48.0836] as for precedent, there's one exemplar of each in ecma262: https://tc39.es/ecma262/#sec-regexpbuiltinexec vs https://tc39.es/ecma262/#sec-stringgetownproperty [12:40:09.0672] I would probably just say "a Temporal.PlainDate"; we do something similar with "an ArrayBuffer" and so on [12:44:31.0343] cool, thanks! 2022-02-26 [19:26:38.0265] having a question about ASI [19:30:03.0051] I'm working on the JSX spec, with JSXElement added to the syntax, for this code: ```js 1 /g ``` will it be interpreted as: NumericLiteral; JSXElement divided by g or it will not have an ASI after `1` so it becomes ```js (1 2 < /video>/g ``` Some comparison and a RegExp literal? [19:34:10.0333] The latter. [19:34:38.0844] oh thanks [19:36:51.0038] ASI only kicks in when there would otherwise be a syntax error. So since "1 < video" doesn't have a syntax error, ASI doesn't insert a semicolon after the '1'. [19:37:22.0159] so ```js 1 ``` it should be `SyntaxError: unterminated regexp literal`? [19:38:19.0729] oh yes, "Uncaught SyntaxError: Invalid regular expression: missing /" [19:41:28.0513] 🤔 tried this code on babel, ts and swc. same result `Unterminated regexp literal`. I think the status quo is good [11:47:38.0247] sort of relatedly but not really relatedly does anyone know why jsx transpilers always call a function instead of just making an object? 2022-02-27 [16:18:01.0635] will it be more likely across various browsers that the objects will share the same hidden class if share the same location? I.e classes are a forrest not a single tree 2022-02-28 [09:01:56.0617] can someone verify my assessment that https://github.com/mishoo/UglifyJS/issues/5370 represents a deviation of V8 from other major implementations in FunctionDeclarationInstantiation with respect to non-simple parameter lists when VarDeclaredNames includes "arguments"? ``` $ eshost -se '[].concat(...["function arguments(){}", "var arguments"].map(occluding => ["()", "(..._)", "(_=0)"].map(params => { const r="return typeof arguments; ", f=Function(params.slice(1,-1), r+occluding); return `${f().padEnd(9)} // function${params}{${r+occluding}}`; }))).join("\n")' #### ChakraCore, engine262, JavaScriptCore, Moddable XS, SpiderMonkey function // function(){return typeof arguments; function arguments(){}} function // function(..._){return typeof arguments; function arguments(){}} function // function(_=0){return typeof arguments; function arguments(){}} object // function(){return typeof arguments; var arguments} object // function(..._){return typeof arguments; var arguments} object // function(_=0){return typeof arguments; var arguments} #### V8 function // function(){return typeof arguments; function arguments(){}} function // function(..._){return typeof arguments; function arguments(){}} function // function(_=0){return typeof arguments; function arguments(){}} object // function(){return typeof arguments; var arguments} undefined // function(..._){return typeof arguments; var arguments} undefined // function(_=0){return typeof arguments; var arguments} ```