2019-06-02 [17:46:41.0000] is there a particular reason that the ecma standard is 262 and the committee is 39? [17:48:04.0000] ok, I see that ECMA has various standards, so it makes sense 262 is only one of them [17:48:09.0000] but does it have other technical committees? :P [17:48:33.0000] apparently it does [19:04:00.0000] react hooks got me thinking [19:04:13.0000] what if there was a way to expose the location of a call expression as a symbol or something [19:04:44.0000] a while ago I made a little clone of hooks that uses tagged templates to this effect but it's obviously a strange api [19:05:57.0000] maybe react hooks are just a bad api and this is a silly topic but imo it does show off some interesting design patterns [21:34:29.0000] the requirement to call them in the same unconditional order imo is a bad API design 2019-06-03 [11:40:24.0000] Has everyone seen TCO: the musical yet? https://www.youtube.com/watch?v=-PX0BV9hGZY [11:59:12.0000] that's amazing [12:24:47.0000] heh, indeed [13:53:12.0000] this is incredible [14:25:39.0000] 👏 too good 2019-06-04 [01:48:26.0000] Jordan, I can hear you [01:49:25.0000] ErrorIsNullError: thanks - on the call? [01:50:34.0000] Yes. [01:55:58.0000] how do I rejoin the delegates channel? [01:56:35.0000] joyee: ping one of the chairs (aki, yulia, brian) to invite you [01:56:51.0000] ljharb: k thanks [01:59:07.0000] joyee: you have access, send `/msg ChanServ INVITE #tc39-delegates` if you can't get in [02:00:08.0000] akirose: got it, thanks [03:16:41.0000] any moddable folks on IRC? can you speak to how hard it would be to not output 'w' in this case? https://github.com/tc39/proposal-for-in-exploration/blob/dcca1337f04ee41567180c551beb94198297ce13/exploration/list-build-order.js [03:17:06.0000] V8, SM, and JSC do not output it (Chakra does) [08:55:37.0000] Is this the document we were talking about in the newcomers meeting? https://timothygu.me/es-howto/ [09:04:05.0000] I wasn't at the newcomers meeting but I can vouch that that is a really good document [11:37:15.0000] bterlson: ping on https://github.com/bterlson/ecmarkup/pulls [11:47:05.0000] gibson042: thanks for the ping, I've merged your recent PRs 2019-06-05 [02:06:58.0000] joesepi: definitely could use some additions though… PR welcome :) [02:08:01.0000] @TimothyGu: I will definitely read through it thoroughly and see how I can help. [02:09:43.0000] great! [03:16:05.0000] Does anyone remember any clashes between user code and specs for the global object? (Not prototype properties/methods.) [03:17:41.0000] Domenic: I can't parse that [03:18:14.0000] unless you mean "why didn't we call `globalThis` `global`"? [03:18:14.0000] Bakkot: like we clashed on Array.prototype.flatMap. But we did not clash on fetch or on Map or Set. Are there any clashes on the global that people remember? [03:18:20.0000] Oh right -_- [03:18:20.0000] ah! [03:18:26.0000] Obviously globalThis is one hehe [03:19:27.0000] global is actually the only one I can think of in js-land off the top of my head, though there might be others from the ES6 days 2019-06-06 [10:14:18.0000] Is anyone around who can answer some questions about the static class features proposal, WRT https://github.com/tc39/proposal-static-class-features/issues/38 ? [10:17:07.0000] I'm assuming static fields are evaluated within the class lexical environment, and don't need any extra bindings like `this`, thus it doesn't need to be implemented as a method, right? [11:41:35.0000] caitp: i'm reasonable sure `class { static singleton = new this(); }` needs to work, if that's what you mean? [11:43:04.0000] I don't think it should work, when `class C { static singleton = new C(); }` would work and do what is expected [11:43:24.0000] makes a lot more sense than rebinding `this` [11:48:54.0000] the class fields proposal explicitly intended that to work [11:49:15.0000] (that `this` directly inside the class body is either the instance or the class) [11:49:46.0000] where on earth is that stated? (that is a bad idea) [11:53:21.0000] why is it a bad idea?? [11:57:01.0000] caitp: https://github.com/tc39/proposal-class-public-fields/issues/50 [11:58:56.0000] it's a bad idea because `this` changes meaning without crossing a function boundary [11:59:26.0000] it adds "the class boundary" as a place where it can change, and matches many people's intuition [11:59:42.0000] similarly, in an instance field, `foo = this`, `this` is the instance [11:59:54.0000] class boundary really should not be a thing [12:00:05.0000] yet there's curly braces there :-p [12:00:21.0000] it sounds like in general you don't like the idea of fields at all tho [12:00:35.0000] the entire proposal is predicated on making "class boundary" a thing [12:01:03.0000] nothing against fields, but `singleton = new this();` isn't any better than `singleton = new ClassName()` [12:01:25.0000] which is arguably significantly easier to reason about [12:01:37.0000] and doesn't prohbit accessing stuff from the real `this` [12:03:16.0000] ClassName is in the lexical scope, has been since day 1, we should use that instead of doing some awkward stuff with `this` [12:03:36.0000] it's better because you don't have to repeat the classname in code [12:03:44.0000] and because not every class has a name at all [12:03:55.0000] ie an anonymous class expression [12:04:09.0000] yeah so the solution there is to not use it in those cases innit [12:04:13.0000] lol [12:04:20.0000] that's one option [12:05:45.0000] I'd rather provide a new metaproperty for people who really want to do that [12:05:58.0000] https://github.com/tc39/proposal-class-access-expressions [12:06:00.0000] call it Self [12:06:04.0000] make the rustaceans happy [12:06:14.0000] either way tho, `this` needs to be the instance inside instance fields [12:06:24.0000] so disallowing `this` in static fields doesn't seem very useful [12:07:09.0000] I don't think you would disallow it, just let it evaluate to the `this` that already exists [12:09:37.0000] that'd be very confusing [12:09:49.0000] because tons of people expect it to be the class itself [12:10:39.0000] I wouldn't expect it to be the class itself, I don't think I've ever written in any language where `this` refers to the class currently being defined [12:11:04.0000] does python do that? maybe python does [12:11:06.0000] but everybody hates python [12:11:55.0000] excluding the possible exceptions of python/ruby/perl, what else does? [12:16:06.0000] but anyways, regardless of all of that, where in the actual proposal does it say any of this? [12:42:05.0000] I would find overriding `this` with yet another meaning in another context to be confusing... [12:43:49.0000] in function expressions you have to specify a name if you want to refer to the function itself (e.g. to call it recursively) -- I would expect the same to be the case with class expressions [12:44:42.0000] How does `this` behave in static methods inside a class today? [12:46:07.0000] FireFly: it's the class [12:46:12.0000] Always? [12:46:14.0000] hmm [12:47:20.0000] alright, I guess it might make some sense (in that "usual rules" of method calls would make `this` be the class if you invoke it as Class.staticMethod()) [12:47:57.0000] But it still seems a bit of a pity to me to add another rule to remember about what value `this` resolves to.. [12:52:02.0000] caitp: i'm not sure where in the current proposal it says that tbh [12:58:00.0000] "Define an own property on the constructor which is set to the value of the initializer expression. The initializer is evaluated in a scope where the binding of the class is available--unlike in computed property names, the class can be referred to from inside initializers without leading to a ReferenceError. The this value in the initializer is the constructor." << that is... [12:58:18.0000] so we can have scope swapping before and after every initializer is evaluated, for no reason [13:00:32.0000] I really don't see this as being something worth having in the spec, from a user perspective -or- implementor perspective [13:01:09.0000] I will be ok with it if computed properties see the same `this` as initializers, but it's still nutso 2019-06-07 [17:12:54.0000] https://tc39.es [17:14:15.0000] woohoo 🎊 [19:52:43.0000] akirose: i don't mean to be a bummer, but search engines downrank .es domains if your language isn't spanish [19:52:57.0000] httpstatus.es had this problem [19:53:07.0000] so they moved to httpstatuses.com [19:55:29.0000] (though it does get a serious boost if your language *is* set to spanish) [23:38:57.0000] huh [03:09:50.0000] devsnek: we also have TC39.org. I’ll put some thought into redirect/canonical/how much I actually care about SEO [03:21:23.0000] akirose: given downstream effects of everyone having to update links and such it'd be nice if that decision could be made quickly, though I understand it's been a long week... [03:22:42.0000] .org might be a little safer long term given the weird things that happen with country TLDs, though I suppose .es should be quite safe [03:43:39.0000] Yeah I’m not feeling… especially concerned about it. [03:44:18.0000] For all of the community outreach and engagement that has been the priority of my chairing, I… don’t especially care about SEO. [03:48:13.0000] it only matters if people would have trouble finding the living spec as opposed to the snapshots [03:48:42.0000] I hope devsnek's not implying that 😱 [07:50:58.0000] clearly the solution is to change the canonical language of ecma262 to spanish, no? [07:55:56.0000] TabAtkins: is there anything I could do to help move https://github.com/w3c/csswg-drafts/issues/4004 forward? [08:01:32.0000] Nah, we just need to discuss it in CSSWG. We just did our f2f, so next call will be in two weeks. [08:02:04.0000] Ok, thanks :) 2019-06-10 [21:42:32.0000] akirose: is there a way to make http://tc39.es redirect to HTTPS? [21:42:56.0000] well, I guess that does redirect, but http://tc39.es/ecma262/ doesn't [22:12:29.0000] Something something github pages? [22:12:49.0000] akirose: yeah I think there's a switch on tc39/ecma262 [22:13:50.0000] I’ll take a peek tomorrow! [23:07:25.0000] TimothyGu: akirose fixed [23:07:35.0000] ljharb: thx [06:38:20.0000] wasn't there an arraybuffer realloc proposal at some point [07:14:09.0000] devsnek: yeah, https://github.com/domenic/proposal-arraybuffer-transfer/, which I haven't had time to get back to. [09:01:14.0000] hey all! Has there already been a proposal on making Math.random reproducible? [09:02:17.0000] it seems like a pretty crucial part of making tests pass, and as there's more and more data science tools for JS, it might be nice to not need to go to external libraries for seedable randomness [09:03:48.0000] towc: https://github.com/tc39/proposal-seeded-random [09:04:14.0000] oh neat! [09:04:15.0000] thanks [09:05:03.0000] oh, I don't know how much I like the choices from that proposal, but it's something [09:05:31.0000] lol [09:05:37.0000] welcome to language design [09:08:57.0000] TabAtkins: can we talk about this? I don't see how you couldn't just have something like `Math.seedRandom()` once. Sure, this would be global and that might be undesired in many cases, but I think it will cover 95% of all seeding needs. A generator could still be used, as another function [09:10:12.0000] `Math.seededPRNG({ seed }).next().value`? [09:10:51.0000] I mean that this is fine. A bit clunky, but fine. I'd just love it if there was going to be a simpler solution for simpler cases [09:11:51.0000] also would be nice to make already existing code (that uses Math.random) be reproducible [09:13:09.0000] and that might require a lot of restructuring, if the only solution is this definition of `seededPRNG` [10:07:46.0000] and how about a way to destructure a default import? [10:08:06.0000] something like `import ({ a, b }) from './exports/default'` [11:19:06.0000] towc: that'd be confusing since `import { a, b }` already isn't destructuring [11:20:19.0000] well, then an additional keyword maybe? [11:21:10.0000] `import default as { a, b } from './exports/default'`? [11:21:22.0000] actually, can you use `as` for this already? [11:23:34.0000] you can `import { a as b }` already [11:23:46.0000] what's the benefit of inline destructuring there? just avoiding a second line? [11:31:03.0000] I'd argue that's pretty important actually [11:31:17.0000] imports should be your first statements [11:31:29.0000] that means that the second line could be quite a ways down [11:31:44.0000] and I don't see why it should [11:32:29.0000] plus, there's one more unneeded item in your namespace, which might not be a big deal, but damn, it bothers me :/ [11:33:12.0000] and I meant using `as` to destructure a default import [11:33:52.0000] if it's possible, I can't get it to work [11:34:19.0000] intuitively, it would be `import itemWhoseNameMightBeThrownAway as { a, b } from './exports/default'` [11:34:33.0000] but that's invalid syntax [11:36:35.0000] or more meaningfully, `import as { a, b } from './exports/default'` [11:37:08.0000] towc: it always could be, but you can put it immediately afterwards [11:37:13.0000] allowing destructuring inline won't force it [11:39:30.0000] I'd rather avoid polluting the "import" part of my scripts [11:39:37.0000] but sure [11:40:45.0000] if your default import commonly needs to be destructured [11:40:52.0000] perhaps it should be multiple named exports [11:41:04.0000] ^ [13:56:22.0000] apparently the airbnb styleguide favours default exports [13:56:53.0000] if you only export one thing* [13:57:29.0000] and when writing tests, if I import named exports at the beginning, and they don't exist, the whole test fails, without going through what could still be tested [13:57:47.0000] oh, it says that? [13:59:00.0000] oh, it does [13:59:02.0000] towc: yes, it favors default exports almost always [13:59:14.0000] well, my linter didn't tell me that [13:59:19.0000] '^^ [13:59:22.0000] towc: the principle is, that a default export is what a module *is*, and a named export is what a module *has*. most every module should *be* something. [13:59:58.0000] how about a `util` module? [14:01:02.0000] certainly that has many things, but i'd also say, don't have util modules :-) [14:01:28.0000] where do you put your generic helpers? [14:01:51.0000] sure, probably someone already wrote something that covers that [14:02:13.0000] but I also don't want to combine many coding styles [14:02:49.0000] a file for each util https://github.com/engine262/engine262/tree/master/src/static-semantics [14:03:08.0000] oheck the ci failed [14:03:24.0000] oh my, that's worrying [14:24:57.0000] towc: i use folders, not files, to group modules. 2019-06-12 [10:24:38.0000] has there ever been something proposed to check if a function can be constructed [11:05:28.0000] devsnek: https://esdiscuss.org/topic/add-reflect-isconstructor-and-reflect-iscallable#content-2 but i don't think anyone proposed it [11:09:37.0000] ljharb: it's in the 2015/01 agenda [11:10:56.0000] oh snap, i have no recollection of it. What happened? [11:17:42.0000] apparently, it wasn't discussed at all [11:21:57.0000] lol [11:46:03.0000] jorendorff: you put the item on that agenda; do you recall why it wasn't discussed/never came back? [11:58:29.0000] ljharb: no, i don't remember [12:01:43.0000] want to put it back on? :-p 2019-06-13 [20:23:56.0000] I vaguely recall there being a discussion, which concluded a few things: adding an alias for typeof === "function" is kind of silly; Reflect is not the right place; and if what's left is isConstructor, do we have any real use cases? [20:34:12.0000] the discussion Domenic is talking about seems to be https://esdiscuss.org/topic/determine-if-a-value-is-callable-constructible [20:34:29.0000] OK, I guess it didn't happen in committee, my memory just assumed it did [20:36:03.0000] And apparently I mostly remembered my own points, so yay [20:36:09.0000] lol [21:06:44.0000] bterlson: [21:06:46.0000] oops [21:07:30.0000] bterlson: is it possible to suppress ecmarkup autolinking for a particular instance? [21:34:39.0000] isCallable would ideally return false for a class, tho [21:35:07.0000] it seems absurd to me to install a [[Call]] slot for no other purpose than to make `typeof` return "function", since we could also change typeof to check [[Call]] or [[Construct]] [07:19:07.0000] isConstructor comes up every once in a while when I'm working on polyfilling something or trying to match certain semantics that engines have [07:20:46.0000] most recently (and what prompted me to post this) was that node's napi can check if something is callable/constructable for napi_new_instance and napi_call and return early, but I can't duplicate this behaviour [08:55:29.0000] Stupid question: in ecmarkup, does the '?' instead of a '!' before a call indicate that it might be nullish or that it might be falsey? [08:56:12.0000] neither, it indicates that the result might be an abrupt completion. [08:56:27.0000] Ah. Thanks for explaining. [08:56:49.0000] So the recursive call in isArray [08:56:51.0000] a. Return ? https://tc39.es/ecma262/#sec-isarray(target). [08:57:22.0000] Is '?' because it might return abruptly if a nested proxyhandler is null. [08:57:36.0000] Err [08:57:46.0000] a. Return ? IsArray(target). [08:58:33.0000] if the top-level arg is a proxy whose target is a proxy whose handler is null [08:59:10.0000] yep [09:02:24.0000] ErrorIsNullError: ? and ! are macros [09:02:54.0000] Thanks for explaining. I see section 5.2.3.4 now. [09:03:06.0000] ReturnIfAbrupt shorthands. [09:03:13.0000] yep [09:03:15.0000] I had been looking in ecmarkup and ecmarkdown. [09:03:15.0000] was about to link [16:05:28.0000] jmdyck: next time, feel free to link https://timothygu.me/es-howto/#completion-records-and-shorthands :) 2019-06-14 [05:26:37.0000] What do you think of `nameof` operator? In C# there is `nameof`, in Swift you can do the same by calling `let keyPath = \Person.mother.firstName NSPredicate(format: "%K == %@", keyPath, "Andrew")`. Let's introduce `nameof` in ES, please. [05:28:31.0000] Devs from TypeScript don't want to introduce this feature in TypeScript unless it is available in ES ( https://github.com/microsoft/TypeScript/issues/1579 ) [07:23:33.0000] gsathya: do you know if computed property names for static class fields are intended to be evaluated before the initializer (like in object literals)? Or is it just sort of UB? [07:27:21.0000] they are computed at class definition time, so yes before the initializer [07:47:09.0000] they're defined on the class at definition time also [07:48:43.0000] but, my question was misguided, for some reason I forgot there was an actual spec in the proposal, not just the github README [07:48:58.0000] so I'm sure it's defined clearly. [14:50:33.0000] ljharb: are you around? [14:51:51.0000] caiolima: yo [14:54:07.0000] ljharb: I'm thinking into change the charset into https://github.com/tc39/ecma262/pull/1135. Also, this is blocking BigInt PR as well and I think we need more reviews, right? [14:54:27.0000] I'm wondering how can we get it... [14:58:03.0000] caiolima: we talked about it in this week's editor meeting; it's high on the list [14:59:33.0000] caiolima: changing the charset seems fine to me [15:00:20.0000] ljharb: Thx for the update! I'll rebase + include change on charset then. [15:05:35.0000] caiolima: great! if you *want* you could also change the base branch of the bigint PR to be the number PR, and then rebase the bigint PR? [15:05:44.0000] that way the diffs will be readable and the merge conflicts will be pre-resolved [15:06:07.0000] (rebase the bigint pr on top of the number PR) [15:06:42.0000] ljharb: SGTM 2019-06-15 [15:32:56.0000] why does everything fail this test https://github.com/tc39/test262/pull/2177/files [15:33:06.0000] even engine262 fails this test, and i can't figure out why [15:48:41.0000] devsnek: they fail an even simpler one: `Reflect.construct(Object, { b: 2 })` matching `new Object({ b: 2 })` [15:49:05.0000] i'm having trouble following why any of these engines fail this though [15:49:27.0000] you mean like, why they're implemented in a way such that it fails? [15:49:39.0000] yeah [15:50:04.0000] my uneducated guess is, Object is legacy, Reflect.construct probably has a bunch of edge case bugs with pre-ES6 builtins [15:50:31.0000] oh wait [15:50:40.0000] `Reflect.construct(Object, [{ b: 2 }])` does work, my bad [15:50:40.0000] doesn't this weird you out [15:51:26.0000] so it's not even Reflect.construct, it's that `extends Object` doesn't seem to work [15:51:49.0000] ie `new class extends Object {} ({ b: 2 }).b === 2` fails [15:52:25.0000] yes [15:58:11.0000] fwiw `constructor(x) { super(x); }` doesn't help though I guess it'd be even more worrying if it did [16:00:59.0000] i legit can't figure out why this doesn't work [16:02:13.0000] rkirsling: that's the default constructor anyway [16:03:32.0000] ugh that reminds me of how annoying this spacing is `constructor(... args){ super (...args);}` [16:03:53.0000] yeah exactly [16:04:06.0000] did they do that just to annoy people [16:04:16.0000] wait where is that spacing from? [16:04:19.0000] the spec [16:04:37.0000] https://tc39.es/ecma262/#sec-runtime-semantics-classdefinitionevaluation [16:04:43.0000] step 10 [16:04:58.0000] oof [16:05:04.0000] if you don't PR that, I might [16:05:10.0000] i was afraid to [16:05:18.0000] like it might start some battle about styles [16:06:36.0000] perhaps. that section appears to be unique though [16:07:09.0000] it's the only place in the entire spec that defines builtin behaviour in terms of source code [16:07:36.0000] usually there'd be a builtin function [16:07:36.0000] yeah I wonder why [16:07:57.0000] maybe that's the real fix? but I don't have the background / have only looked at this for a few seconds [16:08:15.0000] 🤷 [16:08:29.0000] i'm still just trying to figure out why engine262 fails this thing [16:08:34.0000] like even just taking out the spaces there would be acceptable to be [16:08:38.0000] *to me [16:08:46.0000] just any sort of consistency [16:08:51.0000] 'cause there's `f(){}` elsewhere which is fine [16:09:25.0000] as well as the note here: https://tc39.es/ecma262/#sec-declarative-environment-records-setmutablebinding-n-v-s [16:10:02.0000] the code in the string has extra space thouguh [16:10:14.0000] lol true [16:11:41.0000] ok so in this test [16:11:57.0000] active function is `Object` [16:12:18.0000] `NewTarget` is `O` [16:12:45.0000] so it should return OrdinaryCreateFromConstructor right? [16:13:23.0000] that makes me feel like chakra is wrong and everything else is right [16:13:40.0000] am i reading this wrong [16:24:54.0000] https://gc.gy/405dd6cb-02ea-4795-bfe4-8a484a67d3eb.png [16:45:29.0000] huh that is interesting [16:45:53.0000] also #1482 must have containined an ecmarkdown typo [16:46:08.0000] digging for it now [16:46:19.0000] *contained even [16:53:06.0000] lol `<` and... `&rt;` [16:53:18.0000] 👍 [16:54:20.0000] oh hm. that was part of it but evidently not all of it. 2019-06-16 [17:10:27.0000] ah, there was an HTML comment added adjacent to ecmarkdown inside of an

[17:28:57.0000] if it weren't for the ecma262 repo, I still wouldn't know how to git blame from the CLI lol [20:18:54.0000] Hi all, has there been any proposals for the "not" keyword to be added? Searched the repo and came up with none. Particularly, I would love to have the 'not' keyword be used in this manner: if ( "key" not in someObj ) {} [20:55:26.0000] null93: adding a new bareword in unlikely; in this case, it’d have to be a modifier on more than just “in”. also i think there’s far more of a use case for a “has” operator if we’re going to add a new keyword :-) [21:18:25.0000] Understandable, thought i'd throw it out there. Thanks! [21:59:13.0000] rkirsling: can you elaborate on the html comment thing? [22:10:47.0000] rkirsling was probably referring to https://github.com/tc39/ecma262/pull/1482/files#diff-3540caefa502006d8a33cb1385720803R23445 [22:13:51.0000] jmdyck: yeah but i mean, i don't get why that'd cause rendering issues [22:14:55.0000] Did it? Doesn't seem to have. [22:17:14.0000] oh yay, 1245 got merged. [07:46:55.0000] ljharb: sorry, running on jetlag schedule here -- evidently that's what was preventing the markup from rendering. if you build HEAD~2 and ctrl-F for the backtick character, you'll see that instead of 28 results you get over 4700. I didn't dig deeply but the issue seems to be that the comment was directly adjacent to ecmarkdown text instead of another HTML element [08:57:15.0000] rkirsling: gotcha. want to file an ecmarkup bug? :-) ideally it either works or fails to build in that case rather than silently doing the wrong thing [08:57:36.0000] ljharb: may as well :) [08:57:43.0000] yay ty [09:19:23.0000] ljharb: https://github.com/bterlson/ecmarkup/issues/155 [09:22:14.0000] thanks! [09:23:05.0000] my pleasure 2019-06-18 [19:29:27.0000] https://github.com/tc39/test262/blob/master/test/built-ins/Promise/all/invoke-resolve-get-error-close.js [19:29:32.0000] shouldn't returnCount be 1 here [19:29:46.0000] iteratorRecord.Done is false [19:29:49.0000] so IteratorClose is called [19:29:56.0000] which calls the iterator's return [19:30:01.0000] leobalter: cc [19:31:39.0000] seems like everything is failing it now https://test262.report/browse/built-ins/Promise/all/invoke-resolve-get-error-close.js [19:33:02.0000] (whoa unrelated but big woot that XS is on there now too!) [19:33:11.0000] yeah that's pretty cool [19:33:47.0000] maybe one day engine262 will be on there too 🤞 [19:33:56.0000] :D [19:34:15.0000] i've implemented all the recent changes except dynamic import [09:45:54.0000] Who might understand the history behind the requirement for dynamic import "Every call to HostImportModuleDynamically with the same referencingScriptOrModule and specifier arguments must conform to the same set of requirements above as previous calls do." [09:47:54.0000] Is that meant to allow devs to reason about the cost of dynamic import with a constant value in a loop? [09:49:18.0000] Or does this allow some engine implementors to do some extra caching? [09:51:20.0000] ErrorIsNullError: is there something you want to do that requirement prevents? [09:51:52.0000] On the trusted types front. [09:52:12.0000] we'd like to treat import() as a sink and guard it. [09:52:44.0000] import('data:text/javascript,…') has been a CSP bypass. [09:53:10.0000] So I have an agenda, but I'm mostly trying to understand how the pieces fit together right now. [09:53:56.0000] I'm trying to understand the need for that in light of the later requirement in HostResolveImportModule: "This operation must be idempotent if it completes normally. Each time it is called with a specific referencingScriptOrModule, specifier pair as arguments it must return the same https://tc39.github.io/ecma262/#sec-abstract-module-records instance." [09:54:09.0000] to me that just means it can't change over the life of the program [09:54:35.0000] you could block it during linking, or you could allow it, but once it fails or succeeds, it can't change out from under you [09:54:50.0000] My question is more about the intent. [09:55:11.0000] Domenic and littledan can probably speak to that best - the above is just my interpretation of the intent [09:55:11.0000] It seems like an implemenation that did not have the problem would cause confusion. [09:55:20.0000] Thanks [09:56:27.0000] I'll reach out to them. [11:00:13.0000] ErrorIsNullError: as in `import(x)` in one area could work while `import(x)` in another area fails? [11:01:04.0000] i think the intention is that when it succeeds it must always be the same result, not that once it succeeds it must always succeed [11:06:00.0000] Domenic: ^ [11:11:52.0000] devsnek: "That is, if the host environment takes the success path once for a given referencingScriptOrModule, specifier pair, it must always do so, and the same for the failure path." https://tc39.es/ecma262/#sec-hostimportmoduledynamically [11:12:49.0000] yeah in a given module [11:13:24.0000] for csp wouldn't it be different sources [11:15:11.0000] ah right, true [11:16:08.0000] actually for different sources [11:16:40.0000] the rule is always for (referrer, specifier) [11:16:44.0000] not the resulting module [13:18:59.0000] Right, in different modules the resolution can be different, e.g., due to a different base URL (and with import maps, due to scoped maps) [13:19:18.0000] So this is what "with the same referencingScriptOrModule and specifier arguments " is getting at [13:47:37.0000] and i guess import maps can already remap the specifier for a given module to be "nothing" as well? 2019-06-19 [10:48:43.0000] Does anyone know if anyone has proposed a if (let myVariable = ...) { } syntax before? [10:48:45.0000] I couldn't find anything. [10:55:13.0000] interesting...would be surprising if it were never discussed, given its existence in other langs 🤔 [11:02:05.0000] keith_mi_: what's the `...` [11:02:25.0000] usually `if let` is part of pattern matching right? [11:02:30.0000] devsnek: Some expression that you want to bind [11:02:56.0000] like if (let foo = bar.baz()) [11:03:05.0000] keith_mi_: spidermonkey used to have let expressions but not quite that form i don't think [11:03:27.0000] basically any RHS expression [11:03:44.0000] ok, I make a proposal then [11:04:02.0000] is this always truthy? [11:04:04.0000] always falsy? [11:04:09.0000] it looks real odd by today's standards `let (x = y) z` [11:04:38.0000] what is always truthy or always falsy? [11:04:43.0000] like [11:04:48.0000] when does this if block run [11:04:51.0000] it's truthy if the RHS is truthy [11:04:57.0000] yeah, like in C i imagine [11:05:06.0000] i wasn't aware this was a thing in C [11:05:09.0000] but ok [11:05:16.0000] if (let foo = bar()) runs when bar() is truthy [11:05:22.0000] it's sugar for { let variable = expression; if (variable) { ... } } [11:05:27.0000] ok [11:05:33.0000] keith_mi_: real talk do you want the binding to be available in the else branch [11:05:39.0000] no [11:05:42.0000] o really [11:05:52.0000] would interact weirdly with `else if (let` [11:05:52.0000] I mean that's not how any other language does it [11:06:02.0000] you'd just stack up declarations [11:06:16.0000] I guess it's not quite sugar then... [11:06:18.0000] but yeah [11:06:44.0000] I mean we're just talking about https://doc.rust-lang.org/reference/expressions/if-expr.html#if-let-expressions, yeah? [11:06:59.0000] no [11:07:05.0000] that's what i thought this was too [11:07:09.0000] except for the parens difference and the expression difference [11:07:10.0000] no that's doing destructuring [11:07:20.0000] keith_mi_: that breaks with c [11:07:22.0000] which you could do here possibly [11:07:25.0000] keith_mi_: in c the binding is available in both branches [11:07:32.0000] wait really? [11:08:19.0000] oh wow... [11:09:09.0000] idk I'm neutral on it being on both sides [11:09:34.0000] er sorry, I guess Rust is hard to compare with since do exprs and pattern matching are outstanding, but lemme rephrase [11:09:44.0000] c isn't exactly a gold standard of language design [11:10:04.0000] we're talking about C++17 "if auto", right? [11:10:26.0000] it seems gross to me to further conflate assignment with expressions [11:10:28.0000] If we ever had a pattern matching proposal we could choose something else to indicate you wanted a pattern match here [11:10:32.0000] `if (type = x` [11:10:36.0000] type could be auto [11:10:44.0000] i'd rather see us make assignments become statements if it were web compat :-) [11:11:05.0000] something something `let` reserved keyword [11:11:26.0000] hmm yeah I'm inclined to agree that if we did this it should be after Kat and Dave get their stuff through :P [11:11:51.0000] 😱 [11:12:25.0000]