00:20:59  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:26:29  * keith_millerjoined
00:30:26  * keith_millerquit (Client Quit)
00:40:11  * keith_millerjoined
00:41:32  * keith_m__joined
00:44:45  * keith_millerquit (Ping timeout: 244 seconds)
01:12:00  * keith_m__quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:32:41  * keith_millerjoined
01:38:36  * akirosequit (Ping timeout: 250 seconds)
01:38:39  * aki_joined
01:39:03  * aki_changed nick to akirose
01:46:15  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:47:52  * wuz_joined
01:52:11  * wuz_quit (Ping timeout: 246 seconds)
02:01:49  * keith_millerjoined
02:13:32  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:19:20  * Draggorquit (Ping timeout: 250 seconds)
02:23:06  * cloudshuquit (Quit: Connection closed for inactivity)
02:26:54  * keith_millerjoined
02:31:28  * Draggorjoined
02:37:26  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:45:42  * aki_joined
03:45:57  * akirosequit (Ping timeout: 246 seconds)
03:45:57  * aki_changed nick to akirose
03:48:00  * wuz_joined
03:52:33  * wuz_quit (Ping timeout: 250 seconds)
04:23:18  * wuz_joined
04:27:58  * wuz_quit (Ping timeout: 245 seconds)
04:56:20  * keith_millerjoined
04:57:41  * keith_millerquit (Client Quit)
05:13:05  * jmdyckquit (Remote host closed the connection)
05:33:25  * wuz_joined
05:38:18  * wuz_quit (Ping timeout: 268 seconds)
05:52:21  * aki_joined
05:53:01  * akirosequit (Ping timeout: 250 seconds)
05:53:02  * aki_changed nick to akirose
06:53:27  * keith_millerjoined
06:56:32  * keith_mi_quit (Ping timeout: 268 seconds)
07:02:23  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
07:03:20  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:34:02  * wuz_joined
07:38:48  * wuz_quit (Ping timeout: 272 seconds)
07:44:21  * mgoljoined
07:55:14  <annevk>littledan: does OOM for BigInt throw RangeError similar to TypedArray where feasible? We should account for that when structured cloning
07:56:14  <devsnek>annevk: it does in v8
07:56:23  <annevk>When deserializing*
07:56:39  <annevk>devsnek: spec?
07:57:32  <devsnek>afaik the spec doesn't acknowledge that bigints can oom
07:58:07  <ljharb>i don't think it acks it for anything, does it? OOM can happen at any time
07:58:23  * akirosequit (Ping timeout: 245 seconds)
08:00:13  <littledan>Annevk: BigInt is just like String in this respect--no OOM errors are specified
08:00:38  <devsnek>how are there still no other shipping implementations of bigint
08:00:42  * akirosejoined
08:01:47  <devsnek>spidermonkey and jsc are still "in progress" and chakra hasn't done anything beyond a test/mvp
08:03:14  <littledan>I don't know why you put in progress in quotes--those two are nearly done
08:03:39  <littledan>And Chakra has some basic code checked in
08:03:52  <littledan>I am impressed by the speed all around of the project across browsers
08:04:42  <littledan>annevk: Some V8 folks asked about cross-engine shared size limits and specified errors when they are exceeded, but I don't think that makes sense here.
08:06:17  <devsnek>littledan: i just tried searching to see if i could flag either of those to get bigint and couldn't dig anything up
08:06:31  <devsnek>i'd be very happy to be wrong lol
08:07:02  <littledan>Yeah, there are currently build-time flags
08:07:31  <littledan>Our goal for SpiderMonkey is to get this out in nightly in the first quarter of this year
08:07:40  <devsnek>oh yay
08:08:02  <littledan>Igalia doesn't have a client for our work on the implementation in JSC, so that leads it to go a little slower
08:08:10  <devsnek>is it a home-grown solution or are you using a bigint lib
08:08:30  <littledan>Bloomberg has been supporting the SpiderMonkey implementation
08:08:34  <devsnek>jsc doesn't have its own devs to work on it?
08:08:43  <ljharb>wouldn't any igalia client interested in bigint being standardized be interested in multiple impls, even if they don't directly use it?
08:08:54  <littledan>Everyone is using a BigInt library derived from Dart, which has its own long lineage
08:09:46  <devsnek>i suppose dart could output nice inlined operators on like int32s or something
08:09:46  <littledan>ljharb: Mozilla upstream (not a client here) was very interested in this, and we were trying to use various other ones, but this turned out to be the best path technically
08:09:59  <littledan>Writing your own thing from scratch isn't a great idea
08:10:24  <devsnek>i've only seen v8's, which is from scratch
08:10:42  <littledan>It's not from scratch, it's from Dart
08:11:27  <littledan>The thing is, it's hard to use an external library and integrate into the GC system well. So the very long tradition in programming languages is to fork the same code
08:12:43  <littledan>There are (at least) two widely copied lineages of BigInt code going around, the Go/Dart one and the Scheme48 one
08:14:10  <littledan>annevk: I believe the same limit would be used both when creating a BigInt and when deserualizing it, so I am not sure how you would trigger this OOM case
08:14:44  <devsnek>aha i see v8 copied parts from dart and go
08:14:54  <devsnek>i assumed that since it was in the src directory it was all from scratch
08:16:00  <devsnek>aren't all implementations at some level just a list of "digits" that you operate on sorta two's compliment style
08:18:55  <littledan>Yes, but then there's a big variety of algorithms you can use from there! Check out TAOCP volume 1 (no, I have not read all of it) for some fun there
08:19:09  <devsnek>will do
08:19:46  <devsnek>wow this is an expensive book
08:20:04  <devsnek>time for some small-time crime
08:21:39  <littledan>Wikipedia also has some good articles which are way easier to read :)
08:24:31  <devsnek>mfw `O(N log(N) log(log(N))) complexity`
08:30:54  <rkirsling>https://en.wikipedia.org/wiki/Sch%C3%B6nhage%E2%80%93Strassen_algorithm eh
08:31:55  <rkirsling>fascinating to see FFT used to implement multiplication...
08:32:32  <devsnek>`numbers beyond 2^2^15`
08:33:54  <rkirsling>haha
08:35:13  <devsnek>here's something good https://hal.inria.fr/inria-00126462v2/document
08:37:35  <Bakkot>gah, language API design is hard
08:38:53  <Bakkot>I want WeakSet.prototype.union to exist/work. it isn't implementable in userland because WeakSets aren't iterable, but the spec can do it without exposing GC.
08:40:31  <ljharb>Bakkot: it seems like weakset methods might only be able to work with weaksets, not with generic iterables
08:40:32  <Bakkot>but only if it constructs a new WeakSet magically, rather than invoking the WeakSet constructor (because that in turn calls WeakSet.prototype.add, whatever it happens to be at the time). (or the Symbol.species constructor, worse still.) but then that doesn't match the obvious behavior for Set.prototype.union, which presumably _should_ respect Symbol.species.
08:41:26  <Bakkot>ljharb: I am quite happy with that outcome, but it wouldn't match the set methods. and for things like `union` it could work with generic iterables as an argument, in principle.
08:42:09  <Bakkot>but whatever, WeakSets are already pretty weird.
08:42:13  <ljharb>right - i think that "weakset methods match set methods", "set methods all accept generic iterables", "set methods all work with any iterable receiver" might not all work at once
08:42:51  <ljharb>but each of those seems a valuable consistency to have
08:43:58  <ljharb>maybe it'd be easier if all the methods always SpeciesConstructed a collection as needed from any iterable receiver or argument, before doing the operation, but i'm sure that'd be tricky to make work properly with subclassing without adding a bunch of symbol methods
08:44:14  <Bakkot>You can't make that work for WeakSet anyway.
08:44:29  <ljharb>why not?
08:44:47  <Bakkot>oh, sorry, I guess you can as stated
08:44:52  <ljharb>("as needed" meaning it'd have a PromiseResolve-like bailout)
08:45:13  <Bakkot>it's just that for WeakSet.prototype.union you must not SpeciesConstruct the resulting set
08:45:25  <Bakkot>(because doing so would make the contents of the WeakSet observable)
08:45:30  <ljharb>only if you called `add`
08:45:35  <ljharb>if you directly stuck them in the internal slot?
08:45:45  <ljharb>ie, if you reused the alg steps for add without observably calling it
08:46:47  <Bakkot>I mean... that kinda defeats the purpose of SpeciesConstructor, but sure I guess
08:47:17  <ljharb>ohh right i see what you mean
08:47:35  <ljharb>i guess i'd think more like, you SpeciesConstruct an empty one, and .call the internal steps for add on it
08:47:54  <ljharb>and then any of the overridden subclass methods would presumably have to call into the superclass method to work properly?
08:48:47  <Bakkot>depends on your subclass.
08:49:10  <ljharb>yeah
08:49:16  <ljharb>subclassing builtins is weird already
08:50:02  <Bakkot>there's a lot of things a subclass might want to do. if it's just adding new methods, everything's peachy. if it's maintaining some invariants, having something route around its `.add` might well leave it in an invalid state.
08:50:16  <ljharb>true
08:50:32  <ljharb>in that case, subclassability and nonobservability seem to conflict for weakset :-/
08:52:30  <Bakkot>yeah. it's hard to subclass WeakSet properly.
08:55:03  <Bakkot>endorsed: WeakSet.prototype.union should require both is argument and reciever to be WeakSets and should ignore Symbol.species. people should not attempt to subclass WeakSet.
09:08:26  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:14:55  <annevk>littledan: when deserializing ArrayBuffer at least theoretically there could not be enough memory in the process available anymore for the allocation, which would then RangeError which would mean a messageerror event
09:15:37  <annevk>littledan: I was kinda hoping that for new things we would follow the ArrayBuffer precedent and define OOM loosely
09:25:40  <littledan>annevk: I wasn't aware that that was considered to be a new precedent
09:26:18  <littledan>I thought of ArrayBuffers as a thing that tends to be bigger than BigInts
09:26:51  <littledan>I'm not sure there would be compatibility impacts to throwing a RangeError on out of memory conditions to existing types; I don't really see what it has to do with new things
09:28:03  <littledan>maybe we should have this general conversation about these error paths somewhere, rather than thinking of it as restricted to BigInt or new types in general
09:29:00  <annevk>littledan: it's considered one by me, I have no idea about the history 😃
09:29:26  <annevk>littledan: however you want to do this works for me, I just have an interest in getting OOM better defined over time
09:29:41  <littledan>yeah, I've heard this has implications for Wasm
09:30:13  <littledan>one of my over-time wishlist items would be to eventually crash rather than throw a RangeError from stack overflows
09:30:21  <annevk>It seemed reasonable to me that since we had a story for ArrayBuffer, we'd copy that to new things, but I can see that not necessarily being shared
09:30:21  <littledan>which sort of goes in the opposite direction
09:30:37  <littledan>well, it's really hard to implement the RangeError throwing reliably
09:31:00  <littledan>last I heard, in some cases, V8 would throw, and in others it would still crash. It was impractical to include automated tests of this case due to that
09:31:08  <littledan>maybe V8 changed since then, though
09:31:09  <annevk>I see
09:31:40  <annevk>Crashing seems unfortunate for applications, in particular web applications
09:31:46  <littledan>if we want to go this way, i think we should start with a conversation among implementers about what's feasible, rather than just talking in standards-land and saying everyone should throw
09:32:03  <littledan>of course TC39 has a strong bias towards complete definitions and predictability as well
09:32:29  <annevk>littledan: would the BigInt repo be a reasonable starting place or do you want one in the main repo?
09:32:38  <littledan>I think the main repo would be more appropriate
09:32:43  <littledan>and reach more of the right people
09:32:46  <annevk>Okay, I'll write up something short
09:32:59  <littledan>thanks
09:34:11  * wuz_joined
09:39:08  * wuz_quit (Ping timeout: 272 seconds)
09:40:27  <annevk>https://github.com/tc39/ecma262/issues/1391
10:07:17  * aki_joined
10:08:09  * akirosequit (Ping timeout: 246 seconds)
10:08:09  * aki_changed nick to akirose
10:38:49  * mgoljoined
11:13:02  * wuz_joined
11:17:35  * wuz_quit (Ping timeout: 250 seconds)
12:14:31  * aki_joined
12:14:47  * akirosequit (Ping timeout: 240 seconds)
12:14:47  * aki_changed nick to akirose
12:50:03  * jmdyckjoined
13:38:47  * gibson042quit (Quit: Leaving.)
14:20:15  * aki_joined
14:21:19  * akirosequit (Ping timeout: 246 seconds)
14:21:19  * aki_changed nick to akirose
14:35:20  * wuz_joined
14:43:28  * gibson042joined
14:45:12  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
14:55:48  * jwaldenjoined
14:56:32  * gibson042quit (Ping timeout: 246 seconds)
15:05:42  * jorydotcomjoined
15:11:10  * gibson042joined
15:41:24  * gibson042quit (Quit: Leaving.)
15:50:08  * cloudshujoined
16:23:30  * gibson042joined
16:27:22  * akirosequit (Ping timeout: 250 seconds)
16:27:52  * akirosejoined
16:31:38  <devsnek>if a function had a length of 1, and it's called with 0 args, from the implementors perspective that should look like [undefined] right?
16:32:22  <devsnek>and a magical "numberOfArgs" variable set to 0
16:34:38  <ljharb>yes
16:35:02  <devsnek>TimothyGu: ^^^
16:39:49  * keith_mi_joined
16:40:40  * keith_mi_quit (Client Quit)
16:41:18  * gibson042quit (Ping timeout: 245 seconds)
16:45:22  * keith_mi_joined
16:57:54  * gibson042joined
17:04:12  * wuz_quit (Ping timeout: 250 seconds)
17:08:04  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:24:45  * AtumTjoined
17:32:04  * keith_mi_joined
17:35:35  * wuz_joined
17:40:00  * wuz_quit (Ping timeout: 246 seconds)
17:49:02  * wuz_joined
17:57:34  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:03:43  * bradleymeckstares at `function f() {let x = 1; return; {var x = 2;}}; f();`
18:08:34  * keith_mi_joined
18:12:13  <bradleymeck>shouldn't that mean that an early error stops this code from being compiled given https://www.ecma-international.org/ecma-262/#sec-block-static-semantics-early-errors ?
18:12:28  <bradleymeck>you can move the return, it doesn't matter
18:18:33  <devsnek>ecma262 is too powerful for my phone so I can't look
18:21:23  * keith_mi_quit (Remote host closed the connection)
18:21:40  * keith_mi_joined
18:24:42  <bradleymeck>engines are all over the place on how this acts
18:25:01  <jmdyck>the VarDeclaredNames of `var x = 2;` aren't added to the VarDeclaredNames of the function body, I don't think
18:25:03  <bradleymeck>v8 lets it compile, fails on invocation or if you wrap the function with `()` for deeper parsing
18:25:31  <bradleymeck>jmdyck: you can wrap it in a block `function f() {{let x = 1; return; {var x = 2;}}};` if you want then
18:25:50  <bradleymeck>safari it always compiles, always runs
18:25:55  <bradleymeck>firefox never compiles
18:28:54  <jmdyck>I only said "the function body" to avoid saying `let x = 1; return; {var x = 2;}`, so the extra braces doesn't change that. But now I'm thinking I'm wrong in the first place.
18:32:15  <jmdyck>and that it *is* an early error.
18:32:24  <bradleymeck>as long as engines agree idc which it is
18:33:03  <bradleymeck>but right now spec looks like it should be early
18:34:56  * aki_joined
18:35:38  * akirosequit (Ping timeout: 250 seconds)
18:35:39  * aki_changed nick to akirose
18:42:14  <jmdyck>LexicallyDeclaredNames don't bubble up, but VarDeclaredNames do, I think it says.
18:42:21  <bradleymeck>yes
18:43:07  * mgoljoined
18:44:04  <bradleymeck>jmdyck: functions without extra {} also should be error due to https://www.ecma-international.org/ecma-262/#sec-function-definitions-static-semantics-early-errors
18:44:16  <bradleymeck>"It is a Syntax Error if any element of the LexicallyDeclaredNames of FunctionStatementList also occurs in the VarDeclaredNames of FunctionStatementList."
18:53:21  * elyalvaradojoined
18:53:36  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:54:18  * elyalvaradoquit (Client Quit)
19:07:30  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:36:11  * keith_mi_joined
20:07:50  * mgoljoined
20:12:28  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:32:36  * keith_mi_joined
20:38:50  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:41:28  * rektidejoined
20:41:47  * aki_joined
20:43:34  * akirosequit (Ping timeout: 268 seconds)
20:43:35  * aki_changed nick to akirose
20:52:37  * keith_mi_joined
20:52:44  * AtumT_joined
20:55:28  * AtumTquit (Ping timeout: 245 seconds)
20:56:15  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:57:21  * mgoljoined
20:59:42  <Domenic>Is the ordering of methods on e.g. Map.prototype actually defined anywhere
20:59:49  <Domenic>Is it the order they appear in the spec?
21:02:09  <Domenic>https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects could really benefit from sub-headings...
21:03:01  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:05:56  * AtumTjoined
21:07:18  * AtumT_quit (Ping timeout: 250 seconds)
21:17:06  <zenparsing>Domenic: no i don't think so, and there's a wide variance among engines
21:17:24  <Domenic>Fun times
21:17:48  <Domenic>Web specs are similarly undefined, and given the prevalence of partial interfaces it wouldn't even be clear how to do so there.
21:42:05  <ljharb>fun - `Reflect.ownKeys(Map.prototype)` on chrome gives me `["constructor", "get", "set", "has", "delete", "clear", "entries", "forEach", "keys", "size", "values", Symbol(Symbol.toStringTag), Symbol(Symbol.iterator)]` - safari gives me `["forEach", "values", "keys", "clear", "delete", "get", "has", "set", "entries", "size", "constructor", Symbol(Symbol.iterator), Symbol(Symbol.toStringTag)]`
21:50:19  <devsnek>does it matter much?
21:58:57  <ljharb>it'd probably matter if it *were* specified, because then people could rely on it, and adding a new method could break them :-p
22:01:13  * jorydotcomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:02:15  <Domenic>Presumably we'd add a new method at the end
22:02:47  <Domenic>It's a source of non-interop; I know bzbarsky talks about how in the past it's caused interop problems for Firefox with some code-golf competitions/demos that access methods by index instead of by name.
22:05:01  * jorydotcomjoined
22:07:36  * gibson042quit (Quit: Leaving.)
22:08:00  * jorydotcomquit (Client Quit)
22:10:05  * mgoljoined
22:11:53  * wuz_quit (Ping timeout: 250 seconds)
22:12:06  <devsnek>that's kinda yucky though
22:13:19  <cloudshu>bradleymeck: it is my understanding that your example should be an early error
22:13:39  <ljharb>sounds like it's more of a "play it as it lies" code golfing :-p you can't rely on the course always being consistent
22:14:38  <cloudshu>bradleymeck: the way i internalize the rule is, if you replicate a var declaration in every enclosing scope of the actual textual declaration on the way to the nearest enclosing function, and in one of those scopes is a same-named lexical declaration, that's an early error
22:15:26  <cloudshu>(and indeed that's how the spidermonkey parser does the early error checking, which is why it doesn't compile)
22:20:39  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:23:42  <rkirsling>I just fixed that in JSC as a matter of fact :)
22:23:52  <rkirsling>(not for function decls yet but for vars)
22:24:24  * mgoljoined
22:24:47  <cloudshu>oh nice
22:24:57  <cloudshu>function decls don't have that behavior though, unless you mean the annex b weirdness?
22:25:04  <rkirsling>https://github.com/WebKit/webkit/commit/6dbb1ef9af0c44f48be2b68de82dab0ab9279e88
22:25:57  <rkirsling>I'm not sure actually, I just know that there were other redecl tests that I didn't address and they involved the various types of functions
22:26:28  * mgolquit (Client Quit)
22:26:36  <cloudshu>ah
22:26:56  <cloudshu>there's also redecl weirdness around for-of var declarations i think... let me see if i can remember
22:28:01  <rkirsling>yep, it's almost hilarious
22:28:26  * keith_millerquit (Quit: Textual IRC Client: www.textualapp.com)
22:29:17  <rkirsling>copy-pasting an explanation I'd given to a colleague:
22:29:17  <rkirsling>1. lexical scopes aren't var scopes so vars hoist up to function or global scope
22:29:17  <rkirsling>2. as such if that hoisting collides with a let/const declaration it needs to be a syntax error
22:29:17  <rkirsling>3. but wait `try {} catch (e) { var e; }` is legal
22:29:17  <rkirsling>4. but wait again `try {} catch (e) { for (var e of whatever) {} }` is illegal
22:29:37  <cloudshu>yes, exactly it
22:29:37  <cloudshu>https://searchfox.org/mozilla-central/source/js/src/frontend/ParseContext.cpp#461-463
22:30:58  * AtumTquit (Quit: AtumT)
22:34:27  <ljharb>wait, why is that illegal? `function (e) { var e; }` is legal, as is `function (e) { for (var e of whatever) {} }`
22:35:28  <rkirsling>short answer is because Annex B.3 is sadness
22:36:03  <cloudshu>ljharb: only the first is legal, annex b.3.5 baby
22:36:04  <rkirsling>longer answer is
22:36:18  <rkirsling>(I think)
22:36:26  <cloudshu>wasn't the rationale something like for-of is a new construct, so let's make it stricter
22:36:43  <ljharb>wait, so the second one of my examples is illegal?
22:36:49  <ljharb>in sloppy only, or regardless?
22:37:06  <rkirsling>if the catch parameter is destructured or the var is a for-of initializer, then by using such new code you must know what you're doing
22:37:07  <cloudshu>ljharb: wait, i think i read your example wrong, thinking you pasted rkirsling's example
22:37:12  <ljharb>no i typed new ones
22:37:21  <ljharb>i'm saying that if shadowing a function argument is legal, shadowing a catch argument should be
22:37:28  <ljharb>and it's super weird if that's treated differently
22:37:38  <cloudshu>ljharb: catch arguments have always been quasi-lexical and special
22:37:50  <ljharb>right but that's weird :-)
22:37:55  <ljharb>need they be?
22:37:57  <cloudshu>ljharb: i mean... yes
22:38:41  <cloudshu>though i don't see the analogy between parameters and catch bindings, other than that the production used to parse them is the same
22:38:50  <ljharb>to me, they're all bindings
22:39:14  <ljharb>like conceptually, i'm not thinking about parsing or the spec
22:40:02  <cloudshu>what's your reasoning for thinking of them as the same kind of bindings?
22:42:36  <ljharb>they're a variable name that i choose, that's defined inside parentheses directly preceding the block in which they're in scope
22:42:51  <ljharb>and i can omit it :-p
22:45:48  <cloudshu>right, so the syntax similarity
22:46:54  <ljharb>and the semantics of the resulting identifier
22:48:16  * akirosequit (Ping timeout: 250 seconds)
22:48:17  * aki_joined
22:48:41  * aki_changed nick to akirose
22:49:08  <cloudshu>though the kind of scope the blocks following the parentheses is historically different
22:51:01  <rkirsling>probably easier to analogize it with a control flow construct
22:51:50  <rkirsling>one way or another it sucks that the for-of condition is kind of too complex for a developer to memorize
22:52:04  <rkirsling>*...to expect a developer to...
22:52:54  <cloudshu>i can't defend that exception, it seems like a bad idea to me
22:53:17  * mgoljoined
22:53:31  <rkirsling>technically illegal -> legal isn't breaking the web, right?
22:53:43  <rkirsling>I dunno if this is a battle worth fighting, just thinking about it
22:53:53  <cloudshu>rkirsling: right, shouldn't be
22:53:59  <cloudshu>rkirsling: shouldn't be breaking, i mean
22:59:51  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:00:14  * mgoljoined
23:05:46  <devsnek>the solution is to remove varscoped entirely and tell people it's a bug fix
23:15:45  * keith_millerjoined
23:20:00  <rkirsling>thankfully it wouldn't be something that comes up in app code; I imagine transpiler writers would be the primary group to actually be aware of "what happens when I put a var decl in a lexical (or catch) scope"
23:26:33  <cloudshu>function scope oughta be enough for anyone!
23:29:03  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:46:30  <rkirsling>I suppose I could create an issue, seems worth discussing
23:47:54  <ljharb>rkirsling: it'd be most helpful if in that issue, you could document what all 4 browsers currently do in sloppy and strict modes :-D
23:48:10  <rkirsling>can do!
23:48:20  <ljharb><3
23:59:49  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)