2020-03-01 [16:34:43.0000] devsnek: there is an important difference in how they're created, which is that module namespaces are created with internal methods which invoke OrdinaryGet, and proxies are not [16:39:31.0000] i guess? [16:39:52.0000] something about that doesn't sit with me [16:40:34.0000] it helps if you don't think about the spec as being a program so much [16:40:38.0000] you still need to explicitly say a proxy has [[ProxyTarget]] [16:40:44.0000] and a namespace has [[Exports]] [16:40:52.0000] so why don't you need to say an object has ordinary properties [16:41:03.0000] oh, you do: https://tc39.es/ecma262/#sec-object-type [16:41:07.0000] "All objects are logically collections of properties" [16:41:26.0000] *ordinary* properties [16:41:40.0000] what is a non-ordinary property? [16:42:43.0000] Bakkot: where you say "create an own data property" or "create an own accessor property" [16:43:20.0000] those are the kinds of properties which are meant when it says all objects are logically collections of properties [16:43:29.0000] then [16:43:35.0000] OrdinaryGet on a proxy would be valid? [16:43:43.0000] since proxy is a part of that definition [16:43:49.0000] I don't really know what that means? [16:44:15.0000] is your question "are any of the steps in OrdinaryGet nonsensical when applied to a proxy"? [16:44:34.0000] i guess i mean OrdinaryGetOwnProperty [16:44:35.0000] but yes [16:44:58.0000] OrdinaryDefineOwnProperty and OrdinaryGetOwnProperty when used on things like proxies [16:45:01.0000] I believe the answer is no [16:45:13.0000] see, it's the "when used on things like proxies" which is tripping me up [16:45:21.0000] they _aren't_ used on things like proxies [16:45:26.0000] so the "when" is confusing [16:46:28.0000] i'm trying to figure out if all objects have "own" properties [16:47:09.0000] an implementation of the spec could theoretically perform that call [16:47:46.0000] Since the spec does not perform that call, it would no longer be an implementation of the spec [16:48:14.0000] but anyway yes all objects of "own" properties, per the section I linked above [16:48:56.0000] "An Object is logically a collection of properties. Each property is either a data property, or an accessor property. [...] The properties accessible via get and set access includes both own properties that are a direct part of an object and inherited properties which are provided by another associated object via a property inheritance relationship. [...] All objects are logically collections of properties, but there are multiple forms of [16:48:57.0000] objects that differ in their semantics for accessing and manipulating their properties." [16:49:11.0000] left unsaid in that last part is that Proxies do not provide any way of accessing and manipulating their properties [16:50:05.0000] why is using ordinary ops on a proxy out of range if using them on module namespaces isn't [16:50:18.0000] they both provide their own implementation of [[GetOwnProperty]] [16:51:38.0000] When are you thinking an implementation would invoke OGOP on a proxy? [16:52:29.0000] 🤷🏻 [16:52:49.0000] i'm able to do such a thing in engine262 at least [16:53:08.0000] ok, so when does engine262 do it? [16:53:21.0000] never [16:53:23.0000] but it's possible [16:53:32.0000] so i want to make sure engine262 does the right thing if someone did that [16:54:48.0000] so you're asking what the OGOP algorithm means when _O_ is a proxy? [16:55:18.0000] i guess [16:55:40.0000] like if you did OrdinaryDefineOwnProperty and then OrdinaryGetOwnProperty [16:55:45.0000] do you get your property back out [16:55:48.0000] does nothing happen [16:55:51.0000] is the whole thing in valid [16:55:53.0000] invalid* [16:57:30.0000] i think it would create an own property on the proxy [16:57:38.0000] based on what bakkot said about the object definition [16:57:45.0000] but then bakkot also said it isn't valid [16:58:35.0000] I wouldn't say it's *invalid* per se, but the spec never performs such an invocation, so it has no need to define its semantics. [16:59:25.0000] i'd be fine if it was invalid [16:59:30.0000] i just want to figure out some answer [16:59:45.0000] hopefully we can project out of the spec whether or not a certain behaviour is correct or not [17:10:44.0000] Presumably, when OGOP refers to an own property of _O_, that's not a veiled reference to a MOP method, else you'd get infinite recursion. [17:13:49.0000] yeah no that's the actual hook into the implementation's method of storing properties [17:20:45.0000] I guess I'd say that if your implementation calls OrdinaryDefineOwnProperty on a proxy, then OrdinaryGetOwnProperty will 'see' that property. [17:22:40.0000] But again, that's not spec semantics, that's just a possible approach to non-spec semantics. [17:25:58.0000] Another approach would be for the Ordinary* ops to assert that _O_ isn't a proxy. [17:27:05.0000] O is ordinary or a module namespace object [17:27:18.0000] i prefer the less locked down approach [17:27:26.0000] where it just works [17:28:26.0000] Ordinary* ops have to work for more than just ordinary and module namespace objects [17:28:40.0000] hmm [17:28:41.0000] what else [17:30:28.0000] e.g., array's [[DefOwnProp]] has a call to OGOP [17:30:41.0000] oh and arrays [17:30:44.0000] on the array object [17:30:48.0000] i think it makes more sense to just [17:30:54.0000] approach it as working [17:31:02.0000] it seems like that's the approach we take [17:31:08.0000] we can override but always fall back to the ordinary ops [17:31:26.0000] String object's [[GetOwnProperty]] calls OGOP on the String object [17:32:23.0000] and other examples [19:43:56.0000] devsnek: I don't think it is important that the algorithms in the spec be meaningful when used in ways which the spec does not use them in [19:44:25.0000] it is not a library in the programming sense; it is a specification [19:46:37.0000] that is to say, I don't think it is important that one be able to answer questions like "what happens when this algorithm is invoked on this kind of object, which it is never invoked on" [19:48:02.0000] all that said, in this case I do think it happens to work out such that all of the steps in OrdinaryGetOwnProperty would make sense when applied to a proxy, and would manipulate its collection of properties, which it happens to have because the spec says all objects have properties [19:49:10.0000] but the fact that there is an answer to this question, under the current specification, is pretty much coincidence; if we had happened to have an "Assert: O is not a proxy" in OGOP, or in the definition of objects had excluded proxies, there would not be an answer, and that would be OK because it is not the purpose of the spec to answer questions like that [20:06:59.0000] Bakkot: if there was an assert I wouldn't ask [20:14:37.0000] devsnek: in principle there could be an assert for every statement which happens to be true after every algorithm step [20:15:07.0000] they are basically comments [20:16:24.0000] we use them all the time to restrict what abstract ops run on [20:16:43.0000] we use them to clarify why the steps in the abstract operation are sensible [20:16:51.0000] they do not restrict what they run on [20:17:05.0000] the thing which restricts what they run on is, we don't run them on the things we don't want to run them on [20:26:13.0000] ug my messages didn't send [20:55:58.0000] devsnek: i'd say it's not ok to use the ordinary ops directly on a module namespace object either [20:56:05.0000] devsnek: only via their internal methods [20:56:13.0000] eh [20:56:19.0000] that makes no sense to me [20:56:28.0000] abstract ops aren't general purpose functions [20:56:36.0000] that's literally what they are [20:56:41.0000] any usage outside of their explicitly referenced usage is invalid [20:56:44.0000] no, they're not [20:56:47.0000] general logic abstracted out to be used in other places [20:56:56.0000] they're functions that are used for "the exact purpose they're specified for, and nothing more" [20:57:03.0000] not arbitrary places [20:57:08.0000] explicitly enumerated ones [20:58:18.0000] the main question is, why *would* you ever use an OrdinaryGet operation on an exotic objcet [20:58:26.0000] idk [20:58:45.0000] someone can do `AbstractOps.OrdinaryGet(AbstractOps.ProxyCreate())` [20:58:46.0000] ok so, if there's no reason to do it, why is it important that the spec doesn't explicitly forbid it? [20:58:51.0000] well sure [20:58:51.0000] so i wondered what should happen [20:59:02.0000] an incompetent or malicious implementation can do all sorts of things [20:59:26.0000] in this case, does the proxy even have any properties? [20:59:37.0000] its prototype would be via the proxy trap [21:00:03.0000] it does by the definition of objects [21:00:09.0000] people at least agree on that [21:00:23.0000] still up in the air if OrdinaryXyz can be used to access them [21:01:16.0000] it's *capable* of having them, syure [21:01:21.0000] but the only way it could get them is OrdinarySet [21:01:28.0000] and since nothing invokes that on a proxy, how could it get any? [21:01:49.0000] an impl could certainly store things on it, and get them, but no observable JS could, so why is it a question worth thinking about? [21:04:22.0000] ljharb: observable js can't call the ops either so [21:04:26.0000] 🤷🏻 [21:04:28.0000] right [21:04:43.0000] so you're asking a question about a thing that basically can't ever happen :-) [21:04:48.0000] well actually i do have $262.callAbstract [21:04:53.0000] but besides that [21:04:54.0000] sure, within your enginr [21:04:55.0000] *engine [21:05:16.0000] we could certainly add an assertion about what kind of object the ordinary methods are called on [21:05:27.0000] i'm just not sure who it'd be to help [21:05:33.0000] probably no one [21:05:52.0000] all it would do is make engine262 a bit slower cuz i actually check assertions lol [21:06:51.0000] assert is called 1,508,260,158 times during a test262 run [21:07:19.0000] do all the asserts succeed? [21:08:47.0000] yep [21:09:07.0000] there were a few cases where they didn't last year [21:09:18.0000] but i fixed the spec [21:10:27.0000] i think most of the calls are probably from expanding `!` 2020-03-02 [10:32:54.0000] anybody know about https://github.com/tc39/ecma402/pull/302#issuecomment-589999054 ? trying to confirm whether part of the change in https://github.com/tc39/test262/pull/1995 was invalid, which I believe it was, even though SM went along with it... [15:54:05.0000] why does for-of body abrupt completion call iterator.return instead of iterator.throw [15:54:28.0000] s/abrupt/abrupt throw/ 2020-03-03 [16:02:25.0000] devsnek: presumably because the _consumer_ of the iterator hitting an error condition is not the iterator's problem [16:03:16.0000] `.throw` only really makes sense for iterators which do something with the argument to `.next`, so, not the iterators you would use with for-of [16:03:55.0000] i guess there are arguments both ways [16:04:14.0000] what is the argument for calling `.throw`? [16:05:21.0000] something about wrapping streams with async iterators [16:06:07.0000] https://github.com/nodejs/node/pull/32051 [16:07:45.0000] in a push stream model i guess you'd expect the stream itself to own errors that happen while consuming [16:13:01.0000] for a push stream I would expect the stream to be responsible for handling errors which happen while producing values to be pushed, but not for errors which happen while consuming [16:13:16.0000] generally speaking the consumer of some data having an error is not the responsibility of the producer of the data [16:13:23.0000] i mean in the nodejs model it works how i described [16:13:34.0000] because it uses event emitters [16:13:52.0000] `emit('data')` would throw if handlers of the data event throw [16:14:12.0000] or pass an error event or whatever it does [16:14:16.0000] that's pretty unintuitive to me, but ok [16:14:38.0000] in the web platform `dispatchEvent` does not throw even if listeners added by `addEventListener` do [16:14:40.0000] yeah i mean in general i agree with the design in the spec [16:15:38.0000] yeah it just throws [16:16:04.0000] what just throws? [16:16:28.0000] `emit('data')` [16:16:42.0000] i couldn't remember if it threw or made the emitter emit an 'error' event [16:17:14.0000] ah, yeah 2020-03-04 [19:44:44.0000] java beat us to switch expressions [20:10:36.0000] for real? [20:10:46.0000] that's embarrassing, I won't lie [20:10:56.0000] we need to just [20:10:59.0000] make everything expressions [20:22:11.0000] our switch is gross [20:22:15.0000] we need pattern matching [21:29:24.0000] java has a huge advantage over us in adding switch expressions, namely, a type system [21:29:34.0000] switch expressions are a natural fit for java [21:30:57.0000] also I see they're using `yield` for producing the value from the expression [21:31:02.0000] which is neat [21:33:09.0000] actually I guess their switch expressions aren't the thing I was thinking of and aren't really something they're in any better of a position to add [21:33:22.0000] looks like they're adding them mostly because they want to use them with type guards, though [21:33:37.0000] if I am reading the JEP right [21:34:07.0000] I recall they were discussing adding a proper match expression at some point [23:52:11.0000] i'd guess matching is actually pretty easy in modern js engines with all the hidden shape classes [23:52:23.0000] sucks if you don't have that optimization though [07:16:21.0000] devsnek: it gets complicated by transitions not being uniform always. shape x getting a y property added then a z property, might not be the same shape as x getting a z property then a y property [11:46:36.0000] yes whatever did happen to the pattern matching proposal [11:50:51.0000] its champion doesn't seem to be doing much JS stuff anymore [13:14:47.0000] bradleymeck: i just meant its faster than doing complete object comparison with checking individual properties and such [13:57:20.0000] you'll still have to do that for many cases [13:57:28.0000] which is what bradley's saying [13:57:48.0000] hopefully not tooooo often [13:58:12.0000] maybe with libraries like acorn where everything is changing shape all the time [13:58:33.0000] depends on your objects, right [13:59:00.0000] dictionary mode objects aren't that rare [13:59:15.0000] mfw strict mode didn't get rid of delete [13:59:20.0000] i don't even know the last time i used delete [14:13:29.0000] I used it a few days ago, but I can't recall why. [14:14:16.0000] Oh yeah, I wanted to remove a key from an object, duh: https://github.com/tabatkins/railroad-diagrams/blob/gh-pages/railroad.js#L303 [14:14:39.0000] (I iterate the object to set attributes later, so I can't just set it to null or something.) [14:15:52.0000] yeah, strict mode should not have gotten rid of delete; the thing it does is a reasonable thing to want to do 2020-03-05 [16:20:51.0000] was that even on the table? 👀 2020-03-06 [11:09:15.0000] you know how there are some built-in functions whose length is not the obvious thing you would infer from their signature? like the Object constructor has `.length === 1` despite having only an optional parameter. is there a reason we can't just change their signatures to match their lengths? [11:10:03.0000] changing the signature would be making the parameter required, and `Object()` would stop working [11:10:39.0000] where does it say that failing to pass a required parameter to a built-in function throws a type error? [11:11:24.0000] in fact I am pretty sure that is not the case, because e.g. Map.prototype.set requires both arguments, but `(new Map).set()` does not throw [11:12:16.0000] Object.keys ? [11:12:26.0000] i guess that's fair, "required" is a conceptual thing [11:12:41.0000] Bakkot: for Object it might make sense, but it wouldn't make any sense for Date [11:12:55.0000] 1 required parameter doesn't feel "wrong" to me for Object, but 7 feels wrong for Date [11:12:55.0000] rickbutton Object.keys explicitly calls ToObject on its argument, which throws if provided undefined [11:13:01.0000] ah tru [11:13:54.0000] ljharb: sure but what is the benefit of leaving them notationally non-required? [11:14:09.0000] as far as I can tell it is literally just added complexity in the spec [11:14:15.0000] it makes sense? [11:14:18.0000] since it requires explicitly specifying the length [11:14:29.0000] i find that to be far less complex than making the signature conceptually nonsensical [11:14:52.0000] what [11:14:54.0000] ok [11:15:01.0000] ... what [11:15:14.0000] I, uh, do not share that intuition [11:16:24.0000] why is an explicit sentence overriding the length on a few legacy functions "complexity"? [11:17:30.0000] Because now there is another moving part of the spec to understand [11:17:56.0000] It is not "You can infer the .length of a builtin from its signature", it's that "except..." [11:18:56.0000] ok, fair. but your suggestion trades getting rid of that "except" for "now the concept of optional or required is meaningless, because you can't rely on it everywhere" [11:19:15.0000] (because as you noted, "required" doesn't consistently mean "throws when omitted" or anything else) [11:19:37.0000] Is it currently the case that you can rely on it? [11:20:11.0000] afaik. the notation matches what's conceptually required [11:20:22.0000] I guess I don't know what "conceptually required" means [11:20:25.0000] (there's a few DataView/TypedArray cases where it might not) [11:20:36.0000] like, the method needs it to meaningfully work [11:20:53.0000] you can call `.set()` on a map but that wouldn't make any sense, even though it doesn't throw [11:21:07.0000] `.set(foo)` does make sense, it sets to `void 0` [11:21:22.0000] i also don't think that makes sense conceptually (altho i understand what it does) [11:21:37.0000] that's just shorthand for `.set(foo, undefined)`, trading convenience for clarity [11:22:09.0000] omitting an argument is (almost) always shorthand for explicitly passing undefined as that argument [11:22:23.0000] whether it is "conceptually required" or not [11:22:36.0000] that's not universally true, in userland or in the language [11:22:48.0000] lots of things check arguments.length, altho in the spec we've tried to minimize that [11:23:04.0000] yes, hence the "almost" [11:23:09.0000] `Number(undefined)` is NaN, `Number(0)` is 0 [11:23:20.0000] right, but "not always" means that it's not a reliable shorthand [11:23:40.0000] yes but my point is that its reliability has nothing to do with whether an argument is "concdeptually required" or not [11:23:42.0000] and the way you can know it's reliable for Map set, is that the value is required, so omitting it will either assume undefined or throw [11:24:23.0000] that's not what reliable means? [11:25:28.0000] to me it gives a guarantee [11:25:38.0000] "it is either the same, or different", yes [11:25:44.0000] not the world's best guarantee [11:25:44.0000] things that check arguments.length ime only do so around optional arguments [11:26:06.0000] if an argument is optional, omitting it is potentially not the same as passing undefined [11:26:11.0000] thus, the shorthand is ill-advised there [11:26:21.0000] also if the argument is required [11:26:51.0000] i would be very surprised if omitting a required argument was different from passing undefined for it. do you have any examples? [11:27:01.0000] (in the spec, or in reasonably-used userland libs) [11:27:59.0000] `String` [11:28:38.0000] noted [11:29:03.0000] (seems like String.length should be 0 then, in my mental model) [11:29:13.0000] any others? [11:29:47.0000] Not off the top of my head [11:31:02.0000] Oh, looking, `Number` too [11:31:50.0000] but I think that's it among builtins [11:32:03.0000] we're usually pretty good about not surfacing the distinction [11:33:04.0000] ah right, my own example lol [11:43:38.0000] function lengths in js are meaningless to me and I ignore them [12:04:33.0000] ljharb: I think the distinction between optional and required (for built-in fns) is behaviorally meaningless. I.e., indicating that a parameter is optional or required has zero effect on the behavior of the function. The only effect it has is on the default value of the 'length' property. [12:11:20.0000] i agree, it's a conceptual thing 2020-03-08 [12:04:30.0000] proposal: reflect.iscallable and isconstructable (and maybe clean up stuff like symbol which has no business being constructable) [12:23:11.0000] devsnek: michael ficarra ws interested in this the other day, if you haven't talked to him about this yet [12:28:32.0000] actually now that i've woken up and thought about this more i'm not sure how useful it would be [12:28:52.0000] i was just annoyed at this https://cdn.discordapp.com/attachments/222079895583457280/686284194338439248/Screenshot_20200308-114817.jpg [12:35:13.0000] the only reasons I can think to care about it are 1) so you can give better error messages and 2) so you can be more polymorphic; 1 is of slightly dubious value (why is your "is not a constructor" message going to be better than the engine's?) and 2 I am opposed to on principle [12:35:19.0000] but maybe there are other reasons to want it? [12:35:27.0000] I think if you have a good use case the committee would not be opposed [14:34:02.0000] i'm interested in this [14:34:38.0000] in particular it's just nonsense to me to have the concept of `[[Construct]]`, but then also make some things nonconstructible via a throwing [[Construct]] slot 2020-03-10 [22:17:35.0000] i think typed arrays might be the most complex thing in the step [22:17:36.0000] spec [22:20:33.0000] > IsSharedArrayBuffer tests whether an object is an ArrayBuffer, a SharedArrayBuffer, or a subtype of either. 2020-03-11 [02:47:52.0000] wow my impl of GetActiveScriptOrModule was totally broken [02:48:15.0000] and i never noticed because the spec only calls GetActiveScriptOrModule when the top execution context happens to have a non-null ScriptOrModule 2020-03-12 [23:33:08.0000] wow I never actually stopped to notice that you could pin sections while reading the spec [23:33:15.0000] this changes everything [23:44:25.0000] every once in a while i accidentally click it while trying to copy a permalink [23:44:35.0000] that is the entirety of my relationship with pins [23:45:29.0000] ha yeah i never knew about it either [06:53:17.0000] https://es.discourse.group/t/get-iterator-result-in-for-of-syntax/ 🤔 [07:06:09.0000] might be interesting to have an expression form but `for` is soo overloaded already [07:06:54.0000] the completion value differing if it is used as expression vs statement does have precedent with `function`s though [07:40:26.0000] do expressions could be used to get you the return value [07:42:30.0000] ljharb: for ... of doesn't have the right completion value to do that [07:43:09.0000] ah, what’s it’s completion value now, the last thing in the last iteration? [07:44:08.0000] the last completion value of the loop body (if it ran) [07:44:40.0000] ruh roh, is it always undefined if it never ran??? [07:44:53.0000] is it supposed to be undefined or empty.... [07:45:15.0000] > 0; for (let _ of (function* () {yield 1; return 2;})()) { 3; } [07:45:26.0000] if you don't yield I see undefined instead of 0? [07:48:07.0000] ff => 0, v8 => undefined, jsc => undefined [07:48:15.0000] a consistency bug, ripe for the picking [07:50:29.0000] https://tc39.es/ecma262/#sec-runtime-semantics-forin-div-ofbodyevaluation-lhs-stmt-iterator-lhskind-labelset , looks like it is supposed to be fundefined [07:51:13.0000] interesting to know that I cannot propagate completion values through it [08:07:19.0000] 👀 [08:08:05.0000] if someone has IE / non-chrome Edge lying around i'd be curious to know what it is there [09:34:39.0000] I think this is one of the things changed in ES2015 [09:51:31.0000] one of these days I really need to buckle down and figure out Annex B.3.3, but in the meantime, does somebody have a clearer explanation for why this test is valid? https://github.com/tc39/test262/blob/master/test/language/statements/try/early-catch-function.js [09:51:40.0000] namely: [09:52:06.0000] • everyone agrees that `try { JSON.parse() } catch (x) { var x; }` is fine (per Annex B.3.5) [09:53:20.0000] • everyone evidently agrees that `try { JSON.parse() } catch { function x() {} } print(x);` prints `function x() {}` and not `undefined` in sloppy mode [09:53:43.0000] sure, there's no shadowing with that one [09:54:03.0000] `var` being allowed makes sense because `var x` is a noop in that case, and `x = y` is already allowed [09:54:15.0000] • yet somehow `try { JSON.parse() } catch (x) { function x() {} }` does not get the B.3.5 exemption [09:54:19.0000] i can see an argument to allow `function x() {}` in there, but what's the use case [09:55:02.0000] no I just want to make sure I get how the spec is saying that this is so [09:55:28.0000] lol i'm not going to pretend i can understand grammar + annex b + hoisting, hopefully someone can help :-) [09:55:33.0000] because it seems like if it's visible after the catch block, then it's not lexical; yet it doesn't get the var redecl exemption [09:55:48.0000] yeah I was hoping for Bakkot's rescue here 😂 [09:58:02.0000] rkirsling: the reason it's an error is because B.3.3 function declarations act as _both_ a lexical and a var declaration, and `try { } catch (e) { let e; }` is an error [09:58:27.0000] it is in fact [09:58:31.0000] sorry, mistype [09:58:37.0000] "if it's visible after the catch block, then it's not lexical" is false; it is in fact both [09:59:05.0000] I see [09:59:23.0000] I didn't realize "both" was an option due to lack of depth of Annex B.3.3 understanding [09:59:35.0000] apparently this is the "clopen" of the ES spec? :P [09:59:51.0000] it's pretty terrible, yeah [10:00:04.0000] I guess it would be more precise to say that it creates two bindings [10:00:07.0000] not that it is both [10:00:12.0000] but rather that it is one of each [10:02:54.0000] rkirsling: here, just stare at this gist until it makes sense (read: your brain gives up): https://gist.github.com/bakkot/d3bcc42b7938fe2aeebf37eea1ff462d [10:05:27.0000] (editted with a perhaps clearer example0 [10:05:37.0000] ) [10:35:17.0000] (whoops got called away there) wow, this is a doozy [10:35:18.0000] thanks [10:35:59.0000] welcome to adventure [10:54:32.0000] and all that just due to a function redecl [11:40:26.0000] my brain is seriously melting [11:49:32.0000] ohhhh wait [11:54:49.0000] so like, the function decl ends up creating an IIFE-scope var binding for `a` but doesn't initialize it... but it's position is still relevant for the `a` binding earlier in the block... ugh, I'm still not there yet [11:54:56.0000] also *its [12:00:57.0000] rkirsling: updated the gist again with some more probes [12:01:26.0000] <3 [12:01:41.0000] but to summarize: [12:02:20.0000] when B.3.3 is allowed to apply to a function declaration named f, it has the following effects: [12:02:20.0000] - the function gets a `var f;` at the top of it [12:02:20.0000] - the block containing the declaration gets a `let f = function (){}` at the top of it (with the parameters and body of the original declaration, but no name because function expression names are not the same as function declaration names) [12:02:20.0000] - when the declaration itself is reached, it reads from the `let f` (whatever is currently there) and writes to the `var f` [12:02:51.0000] sorry, that first line should be "the function (or script) containing the function-declaration-in-a-block [...]" [12:04:18.0000] another person inducted to b.3.3 understanding? [12:04:21.0000] one of us one of us [12:05:12.0000] i tried to get the last bullet of Bakkot changed a while back because the first time i implemented i felt so personally affronted by the semantics [12:06:08.0000] but i have since then matured as a person [12:06:26.0000] also B.3.3 doesn't actually capture what browsers do yet; see https://github.com/tc39/ecma262/issues/913 [12:07:31.0000] oh man i wrote that? [12:07:37.0000] no recollection [12:08:04.0000] counterfactuals in semantics: not a good time [12:10:41.0000] rkirsling: you'd appreciate the difficulty. the way i learned how to model counterfactuals is possible worlds a la kripke. is it time for modal logic in ecma262? [12:17:31.0000] =D [12:18:51.0000] hell yeah [12:20:53.0000] create a successor world and then jettison it after [12:21:47.0000] (admittedly that's a very imperative way to put it but alas) [12:23:23.0000] Bakkot: thanks for all that; I'll be sure to store this in writing somewhere for myself [12:23:56.0000] someday I should write it up and publish it somewhere so I can link it instead of reproducing it from memory every time [12:24:07.0000] actually there ought to be a tales-from-the-ES-crypt blog post about this yeah [12:24:28.0000] lol, "ecma's crypt" [12:24:38.0000] this needs to be a blog [12:24:55.0000] a "wat" talk only 5 people can appreciate [12:25:03.0000] 😅 [12:25:20.0000] I APPRECIATE [12:25:20.0000] OMG [12:25:26.0000] ECMA'S CRYPT YES [12:25:43.0000] my favorite right now is `typeof new Proxy(document.all, {})` [12:25:50.0000] (it's "function", because of course it is) [12:25:52.0000] stop that's illegal [12:25:53.0000] http://images4.wikia.nocookie.net/__cb20100602135929/uncyclopedia/images/thumb/c/c4/CryptKeeper.gif/450px-CryptKeeper.gif [12:26:00.0000] how is that function [12:26:06.0000] document.all is callable [12:26:06.0000] document.all doesn't have a call slot [12:26:08.0000] what [12:26:10.0000] sure does [12:26:22.0000] oh and it returns null [12:26:23.0000] classic [12:26:36.0000] when called with no arguments [12:26:50.0000] https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#HTMLAllCollection-call [12:27:58.0000] like i understand why they did the whole falsish thing [12:28:07.0000] but why is it a function too [12:29:17.0000] Bakkot: make it revocable bro [12:29:23.0000] it's called `all` for a reason [12:29:32.0000] devsnek it was already a function in IE [12:30:09.0000] the answer to the question "what type is document.all?" is of course "yes" [12:30:47.0000] (I guess it's unequivocally not a number though lol) [12:33:06.0000] could some recommend a CLI js pretty printer? [12:33:40.0000] what is the clang format of js, prettier? [12:34:00.0000] there's no one answer. prettier's probably the fastest out of the box for you [12:34:20.0000] prettier [12:34:32.0000] the most common is eslint with airbnb's config, but "standard" and "prettier" are both pretty frequently used too [12:34:49.0000] prettier is the most common as a CLI tool by far [12:34:56.0000] as a standalone one, true [12:36:02.0000] shu: you can `npx prettier file.js` to pretty-print any JS file without even installing prettier, as long as you have modern node on your computer [12:36:05.0000] we could make an official tc39 one and destroy the community forever [12:36:17.0000] though probably you want to install it [12:36:39.0000] devsnek nah, no one listens to us [12:37:33.0000] fun trivia [12:37:38.0000] when jetbrains was making webstorm [12:37:43.0000] ...except when we try to take away their precious ASI [12:37:48.0000] they made standardjs the default formatter for js [12:37:53.0000] because they thought it was an actual standard [12:38:26.0000] yeah I am still mad about feross's decision to name it that [12:38:50.0000] cool thanks [12:40:28.0000] still not too late to make StandardsJS [12:40:34.0000] just sayin' [12:41:25.0000] StandardizedES [12:43:45.0000] ljharb: also it looks like prettier gets 3x the number of weekly downloads as eslint-config-airbnb; is there a different number somewhere you're looking at? [12:44:18.0000]