00:08:05  * mattijsquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:09:26  * bradleymeckjoined
00:09:31  * mattijsjoined
01:04:06  <Bakkot>mootools defines `Array.prototype.flatten` in a way incompatible with the proposal
01:04:09  <Bakkot>so I guess that's dead
01:04:12  <Bakkot>everything is terrible
01:06:55  <Domenic>Bakkot: does it do if(!Array.prototype.flatten) or does it just override?
01:07:12  <Bakkot>As of 8 years ago it just clobbers, but prior to that it was conditional, so it breaks.
01:07:31  <Bakkot>Firefox ran into this in the wild: https://bugzilla.mozilla.org/show_bug.cgi?id=1443630
01:11:30  <cloudshu>bootools
01:18:13  <ljharb>wattt
01:18:45  <ljharb>Bakkot: what's the way that it defined it that's incompatible?
01:19:01  <Bakkot>infinite depth by default, probably
01:19:02  <ljharb>we could still do flatMap with a depth argument and `x => x` as the mapper, i guess :-(
01:19:09  <Bakkot>at least, I know it has that incompatibility, and suspect that is the breaking one
01:19:11  <ljharb>ah - we could make that change tho
01:19:28  <Bakkot>mficarra will die before letting that change go in
01:19:46  <Bakkot>See alternative solution https://github.com/tc39/proposal-flatMap/pull/56
01:19:48  <ljharb>perhaps he'll re-evaluate if the alternative is killing flatten tho
01:20:00  <ljharb>rofl
01:20:20  <Bakkot>he will not.
01:20:33  * Jayfluxquit (Ping timeout: 248 seconds)
01:21:01  <ljharb>:-/
01:21:03  <ljharb>i'm not sure why
01:21:14  <ljharb>i prefer 1 by default too, but the method is important to have
01:21:43  <Bakkot>I'd be fine with .smoosh instead!
01:21:48  <ljharb>lol
01:21:56  <ljharb>sMOOshTools
01:23:03  <domfarolino>I noticed in #sec-object-type it says "The properties accessible via get and set access includes both..." own and inherited properties, but isn't it true that a setter cannot set inherited properties?
01:23:44  <cloudshu>Bakkot: motion for all new methods on primordials to be onomatopoeia
01:24:15  * keith_millerjoined
01:24:35  <Bakkot>cloudshu: seconded, let's do it
01:24:40  <Domenic>smooshMap?
01:25:41  <not-an-aardvark>`Array.prototype.splatten` and `Array.prototype.splatMap`
01:26:10  <not-an-aardvark>ah, the first one apparently has a different meaning than I intended
01:26:43  * mattijsquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:28:15  <domfarolino>Ah, so then it says inherited properties = own properties + inherited properties, which is interesting + recursive
01:29:28  * caridy_quit (Remote host closed the connection)
01:29:39  <Bakkot>domfarolino: I would consider `a.b = c` to be "set access", and that can invoke an inherited setter, so that language seems right to me.
01:30:01  * caridyjoined
01:31:17  * caridy_joined
01:31:17  * caridyquit (Read error: Connection reset by peer)
01:32:30  * gibson042joined
01:34:13  <jschoi>Squash.
01:34:56  <jschoi>…also might be an okay synonym.
01:35:16  <domfarolino>Bakkot: Ok yeah, that makes sense whoops
01:35:51  <bterlson>radical idea: compat hacks?
01:36:09  <bterlson>like, make the function falsy in scripts?
01:36:39  <ljharb>Bakkot: btw can we make sure not to merge that rename PR pre-meeting?
01:36:58  <bterlson>also, +1 squash, -1 smoosh
01:38:03  <Bakkot>no oh god please no compat hacks
01:38:25  <bterlson>it gives us back the global namespace
01:38:43  <not-an-aardvark>Could we make the default compatible with mootools (i.e. `depth = Infinity`)?
01:38:52  <Bakkot>Only if people are using `if (!obj.prop)` instead of `if (!('prop' in obj))`
01:39:04  <Bakkot>I do not want to have another ULEO
01:39:21  <cloudshu>i forget what that stands for everytime
01:39:29  <bterlson>undefined-like exotic object
01:39:29  <cloudshu>undefined-like-??-object
01:39:31  <cloudshu>ah ok
01:40:06  <bterlson>I would be finie with depth = Infinity too if that's all it takes
01:40:21  <ljharb>same
01:41:30  <bterlson>*fine
01:41:58  <ljharb>i also think the default for the depth arg is a weird hill for the proposal to die on.
01:47:53  <devsnek>could just throw the feature as-is into all dev browser releases for a few years and the problem will fix itself :)
01:48:25  <bterlson>devsnek: that's an interesting idea, I wonder how effective that is...
01:48:47  <bterlson>though part of the problem is sites which have no developer
01:48:49  <devsnek>i suggested that to ljharb when `global` got blocked by flickr mostly as a joke
01:49:10  <ljharb>also the issue is that devs don't universally use dev builds.
01:49:37  <devsnek>console warnings etc
01:49:42  <devsnek>i dunno
01:49:55  <ljharb>lol i've never even worked at a company where every web dev checks the console.
01:50:07  <devsnek>hire skywriters
01:50:43  <not-an-aardvark>there are a finite number of sites that would be broken by `Array.prototype.flatten`, and in principle they could all be fixed. But based on what happened with `Array.prototype.values`, people will probably still be using old sites even if they're not under active development.
01:51:01  <Bakkot>Yeah, I'm pretty sure there is no path to getting the web to fix itself here.
01:51:29  <devsnek>'use es2018' :^)
01:51:40  <bterlson>skywriters could work, but the fuel costs would be a little steep
01:51:48  <Bakkot>where by "pretty sure" I mean "overwhelmingly confident". we might get away with only breaking things which almost no one uses anymore, but that's still imo not acceptable.
01:52:09  <devsnek>i wouldn't mind if my old websites were broken in the name of making js better
01:52:38  <not-an-aardvark>Unfortunately not everyone cares about making js better, and many people care if their website breaks
01:52:39  <devsnek>and if you care enough about your old websites that they don't break you should be able to keep them updated
01:53:14  <Bakkot>Even if a webdev doesn't care, their users do.
02:01:31  <not-an-aardvark>This is one step above a ULEO, I guess https://gist.github.com/not-an-aardvark/2f9b6d198de70892db02e171be6184c3
02:14:08  <devsnek>that's pretty cool
02:14:22  <Domenic>I think we should explore bterlson's skywriters option in more depth. After all, we have all these Ecma dues.
02:17:58  <not-an-aardvark>Sorry, we can only explore it in 1 depth. If we wanted more depth we could just use the mootools version.
02:18:44  <devsnek>🔥
02:22:57  * bradleymeckquit (Quit: bradleymeck)
02:53:51  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:57:54  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
03:01:16  * caridy_quit (Remote host closed the connection)
03:05:18  <cloudshu>Domenic: when google bought chelsea market did they buy the air rights
03:05:29  <cloudshu>can google do skywriting on just that area
03:05:46  <devsnek>kek
03:39:15  * bradleymeckjoined
03:50:04  * bradleymeckquit (Quit: bradleymeck)
04:18:07  * caridyjoined
04:34:24  * caridyquit (Remote host closed the connection)
04:39:49  * caridyjoined
04:51:55  * caridyquit (Remote host closed the connection)
05:11:13  * jmdyckquit (Remote host closed the connection)
05:28:24  * caridyjoined
05:32:49  * caridyquit (Ping timeout: 248 seconds)
07:34:02  * keith_millerjoined
07:34:24  * keith_millerquit (Remote host closed the connection)
07:34:56  * keith_millerjoined
08:18:32  * Draggorquit (Ping timeout: 276 seconds)
08:23:17  * Draggorjoined
08:32:47  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:32:29  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
11:25:10  * mylesborinsquit (Quit: farewell for now)
11:25:41  * mylesborinsjoined
11:41:00  * jmdyckjoined
11:41:47  * Jayfluxjoined
11:41:47  * Jayfluxquit (Changing host)
11:41:47  * Jayfluxjoined
11:48:24  * keith_millerjoined
11:54:01  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:01:31  * Jayfluxquit (Remote host closed the connection)
12:45:42  * keith_millerjoined
12:49:37  * AtumTjoined
13:02:55  * bradleymeckjoined
13:21:37  <evilpie>ugh people behave terribly on github
13:21:47  * howdoiquit (Quit: Connection closed for inactivity)
13:53:35  * bradleymeckquit (Quit: bradleymeck)
14:33:05  * bradleymeckjoined
14:50:02  * Jayfluxjoined
15:01:02  * Jayfluxquit (Remote host closed the connection)
15:01:41  <littledan>evilpie: That discussion at https://github.com/tc39/proposal-flatMap/pull/56 is really surprising to me; I thought developers would want us to not break their pages. I guess it's fine if it's "some else's" page.
15:01:55  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:02:33  <evilpie>github is not representative for stuff like this
15:53:00  * caridyjoined
16:05:05  * Jayfluxjoined
16:14:00  * bradleymeckquit (Quit: bradleymeck)
16:34:46  * mattijsjoined
16:46:25  * bradleymeckjoined
16:52:57  * keith_millerjoined
17:01:44  * Jayfluxquit (Remote host closed the connection)
17:11:34  * rwaldronjoined
17:12:17  * rwaldronquit (Client Quit)
17:16:07  * rwaldronjoined
17:22:40  <devsnek>i think a lot of people don't care if their old websites get broken in the progression of js and they don't realise that other people don't feel the same way
17:26:05  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:31:33  <TabAtkins>FWIW, I agree with Domenic that the flatten/flatMap naming connection is nice, and if we do rename flatten, we should rename flatMap. I disagree that we should exactly follow the naming, tho - no need for smooshMap - instead, we should skip over to the other naming pattern and call it .chain().
17:31:44  <TabAtkins>(I can't comment on the issue as I'm not a collab.)
17:33:37  <TabAtkins>littledan: As a general rule, you will *always* find devs that have *very strong* bad opinions about the browser compat. The same type of people will, of course, be the first to yell about their sites breaking when we *do* make a compat-breaking change. It's not about having a consistent view of compat, it's about having the committee do what's personally best for them, without taking the larger view of the health of
17:33:37  <TabAtkins>the web.
17:33:44  <bterlson>TabAtkins: #smooshMap
17:33:48  <TabAtkins>nO
17:33:54  <TabAtkins>Bad bterlson!
17:34:22  <littledan>TabAtkins: Weird. How do you make the committee open to feedback while having this sort of culture?
17:34:23  <TabAtkins>That gif makes me extremely happy tho.
17:34:43  <bterlson>littledan: you just have to take the feedback in the proper context
17:34:47  <TabAtkins>littledan: You carefully cut off threads that get bad attention. It's pretty random what things will draw the lightning.
17:35:11  <littledan>OK, this is frozen now; should we have done that several hours ago?
17:35:14  <TabAtkins>Like all communities, there will *always* be a small minority of loud jerks that you have to handle.
17:35:21  <TabAtkins>Yeah, I would have. ^_^
17:35:31  <littledan>OK, it's my first time freezing a thread so I was timid!
17:35:37  <TabAtkins>(I did see that it was frozen, you did good.)
17:35:41  * mattijsquit (Ping timeout: 276 seconds)
17:36:17  <TabAtkins>Freezing is something to do with care! Too free with it, and people feel shut out. But you quickly learn what sorts of discussions are productive and which are just rehashes of the same no-content discussions.
17:36:21  <bterlson>tabatkins I can make you a collab on that repo if you like?
17:36:28  <TabAtkins>If you want?
17:36:32  <bterlson>k
17:36:36  <littledan>offtopic: I need to avoid adding extra microtask queue delays, so I'm using a callback style instead of Promises... internally in a spec
17:36:44  <littledan>TabAtkins: You can join the TC39 delegates group if you want, as a Googler
17:36:52  <TabAtkins>Oh!
17:36:54  <TabAtkins>how do
17:37:00  <bterlson>littledan: oh duh
17:37:05  <bterlson>I'll just add him to Delegates
17:37:38  <littledan>invited
17:37:53  <bterlson>oh thanks
17:38:20  <TabAtkins>danke
17:38:46  <littledan>anyway how strongly do people feel about the way that you can observe how many microtask delays each thing has? It seems kind of random due to internal spec mechanics how many turns things work out to today, but then it's observable and you can't take shortcuts (or longcuts) in an implementation or spec
17:39:19  <littledan>everything would be great if we just... made the microtask queue have undefined ordering
17:40:01  <devsnek>there were some okay ideas in that github issue even if overall it was too heated
17:40:23  <bterlson>I dunno how much moderation work littledan had to do but there was a lot of swearing last night before I went to bed
17:40:29  <devsnek>yea definitely
17:40:38  <littledan>I only deleted one thing; I didn't see a lot of swearing
17:40:41  <littledan>maybe someone else did
17:40:50  <devsnek>i've been mostly thinking about in the future ways to get around this general issue
17:41:14  <devsnek>people will always add weird things to primordial prototypes
17:41:48  <bterlson>the era of emoji intrinsics are coming folks
17:42:20  <bterlson>win + . + wink <enter> = 😉
17:44:16  <devsnek>have you guys discussed this as a more general problem at meetings before
17:44:29  <bterlson>devsnek: yeah a number of times
17:44:39  <bterlson>devsnek: e.g. built-in modules were motivated by this problem in part
17:44:57  <devsnek>import smoosh from Array (no quotes)
17:45:12  <TabAtkins>(This is why I'm very glad I stuck to my guns with "CSS custom properties need a distinguishable prefix" policy.)
17:45:14  <devsnek>i forgot some brackets tho
17:45:32  <bterlson>devsnek: I had a similar idea! Naked identifiers in module specifier position = built-ins
17:45:41  <devsnek>yea
17:45:45  <bterlson>there were some issues with it that I will try to find
17:45:51  <TabAtkins>(And "no, we'll never add pluggable error-recovery".)
17:46:17  <devsnek>the thing that sticks out to me is that its a change in module parse with no clear transition path
17:46:25  <devsnek>no way to detect etc
17:47:01  <devsnek>need a new parse goal "modules_v2"
17:48:41  <littledan>oh my god pluggable error recovery
17:48:42  <TabAtkins>Hmmmmm. Stick with me here. 1. Add new things into the built-in modules, yes. 2. Allow *-importing of stuff in that module *by date*. 3. Make future dates some hard error so you can't cheat.
17:48:47  <littledan>it's already the worst feature in CSS
17:49:26  <TabAtkins>CSS's error recovery is its *best* feature, shut your mouth. ^_^ But I mean having a callback for "uh, this property doesn't parse, you figure it out for me".
17:49:28  <littledan>TabAtkins: So what do you think when you hear about how everyone hates # ?
17:49:46  <TabAtkins>The # glyph in JS?
17:49:49  <littledan>yeah
17:49:59  <TabAtkins>What's the context here, this feels like a complete topic switch.
17:50:12  <littledan>oh, you were talking about distinguishable prefixes for CSS custom properties
17:50:18  <littledan>and we've had a similar debate in TC39
17:50:33  <littledan>where many people in the community don't like the committee's idea to make private field names start with #
17:50:48  <littledan>but, we have technical reasons for why it has to be syntactically distinguished somehow or other, and this is the best we got
17:50:57  <devsnek>its only because it makes it easy to distinguish as a sentinel right?
17:51:33  <littledan>anyway sorry about error recovery, I get how it helps evolution sometimes, that comment of mine was not right
17:51:36  <TabAtkins>Oh, ok. Yeah, I just had to be like "too bad, this is important" and ignored the feedback to the contrary. I did still *listen* - that motivated the switch to using -- as the prefix, which I think was a good move.
17:51:45  <devsnek>and i guess stops access from outside
17:51:53  <littledan>what was the previous prefix?
17:51:54  <devsnek>which helps with perf
17:52:02  <TabAtkins>First was "var-", then "_".
17:52:22  <littledan>heh, in this case, lots of people wish it were _, but it can't be
17:52:29  <littledan>or the other candidate is @, but that has problems too
17:52:35  <TabAtkins>Clearly the answer is dunder.
17:52:39  <TabAtkins>And if not that, TRUNDER
17:52:48  <TabAtkins>Q U U N D E R
17:52:55  <littledan>I'm not sure, we may need a lot of unders
17:53:12  <TabAtkins>(quunder works for four *or* five, it's a parsimonious word.)
17:53:20  <devsnek>if it was just a normal variable name like `private xyz` it could still be compiled into a private symbol
17:53:26  <devsnek>is the issue with external property access
17:53:33  <devsnek>or injecting prototype methods?
17:53:39  <devsnek>or smth
17:54:50  <Bakkot>devsnek: https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md
17:56:07  <littledan>Me: this breaks my site. My site: class C { renderSite() { for (let i = 0; i++; i < 100000000000) { try { eval("_".repeat(i)); assert(false); } catch (e) { assert(e instanceof ReferenceError) } }; document.write("my site"); } } new C().renderSite();
17:56:30  <devsnek>lol
17:57:53  <littledan>(I wanted to use BigInt but that'd throw a TypeError early on for its use in repeat)
17:58:30  <devsnek>hmm that actually reminds me
17:58:38  <devsnek>methods in js stdlib that take numbers
17:58:44  <devsnek>like String.prototype.repeat
17:58:52  <devsnek>would those ever be able to also take BigInt
17:59:30  <TabAtkins>Should, I'd think.
17:59:44  <littledan>devsnek: The current plan is, no. Things only take BigInt when they really need a big value. Otherwise, stick with Number
17:59:55  <devsnek>i feel like thats a bit of an oversight
18:00:17  <littledan>well, it's a deliberate design decision. Ultimately, we can't make BigInt and Number interact seamlessly
18:00:27  <devsnek>i didn't mean you should
18:00:33  <devsnek>since you can't work with bigint and numbers at the same time people will generally be using one or the other
18:00:49  <littledan>right, that's my hope for how people will use them
18:01:01  <littledan>that you'll be aware of what you're working with and stick with that
18:01:10  <devsnek>so i don't want to do like Number.fromString(xyz.toString()) every time i want to use builtin methods
18:01:24  <devsnek>assuming my bigint fits into a number
18:01:45  <littledan>if you know your BigInt will fit into a Number, just use Numbers already
18:01:51  <devsnek>what if i don't know
18:02:10  <littledan>BigInt is designed to be deliberately unergonomic for things like what you described, since you'll get a wrong answer if it doesn't fit
18:02:22  <devsnek>thats my point :/
18:03:04  <littledan>I mean, it's case by case. For String.prototype.repeat, I think it just doesn't work semantically. You won't have enough memory to hold the result, unless it's the empty string
18:03:33  <devsnek>well doesn't the spec limit the length of a string to Number.MAX_INTEGER
18:03:37  <devsnek>or something like that
18:03:58  <devsnek>2^53-1
18:05:50  <littledan>JS programs are generally intended to run on computers, which are only so big
18:06:08  <devsnek>fair point
18:06:23  <bterlson>littledan: false, ES mandates infinite memory
18:06:36  <bterlson>:-P
18:06:47  <devsnek>but i think it isn't unreasonable to expect that if i call Math.max with all bigint arguments it should "just work" instead of throwing an error about coercing to a number
18:07:18  <littledan>well, we talked about specifically overloading Math.max
18:07:50  <littledan>maybe we could still add that, I can't remember the reason for not supporting it
18:08:07  <littledan>for Math.pow, we opted to keep it Number-only; you can use ** on BigInts
18:08:13  <littledan>the others don't really make sense on BigInts IIRC
18:08:58  <littledan>generally, the design is, you *dont* get free overloading everywhere--basically only for operators, where it's necessary, otherwise there's risk that people will try to cast to Number to use operators
18:09:05  <littledan>and generally bad ergonomics
18:09:09  <devsnek>it doesn't have to be overloading
18:09:22  <devsnek>er
18:09:28  <devsnek>i said that wrong
18:12:56  * keith_millerjoined
18:14:25  * kaalchakkajoined
18:36:07  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:42:18  * kaalchakkaquit (Quit: ZZZzzz…)
18:46:57  * keith_millerjoined
18:58:58  * bret_joined
19:00:25  * kaalchakkajoined
19:05:00  * kaalchakkaquit (Client Quit)
19:07:16  * jmdyck1joined
19:07:40  * jmdyckquit (Ping timeout: 240 seconds)
19:12:58  * kaalchakkajoined
19:17:04  * bret_quit (Ping timeout: 260 seconds)
19:31:50  * caridyquit (Remote host closed the connection)
19:32:36  * caridyjoined
19:49:29  * kaalchakkaquit (Quit: ZZZzzz…)
19:50:25  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:52:01  * AtumT_joined
19:52:07  * bradleymeck_joined
19:52:32  * bradleymeckquit (Write error: Connection reset by peer)
19:52:33  * AtumTquit (Read error: Connection reset by peer)
19:52:33  * bradleymeck_changed nick to bradleymeck
20:01:12  * kaalchakkajoined
20:03:28  * mattijsjoined
20:06:49  * mattijs_joined
20:07:13  * efaustjoined
20:07:57  * mattijsquit (Ping timeout: 252 seconds)
20:08:21  * jorendorffjoined
20:08:35  * jwaldenjoined
20:30:30  * kaalchakkaquit (Quit: ZZZzzz…)
20:33:08  * keith_millerjoined
20:40:20  * mattijs_changed nick to mattijs[away]
20:40:50  * mattijs[away]quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:58:50  * rwaldronquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:11:39  * kaalchakkajoined
21:15:32  <littledan>devsnek: What do you think it should be?
21:22:51  <devsnek>I dunno if you'd call it overloading, but like, people are used to type checks based on the input of functions
21:23:00  <devsnek>I guess that is a form of overloading
21:23:26  <devsnek>the idea is though, the function is not coercing anything
21:36:11  <bradleymeck>dynamic dispatch?
21:42:40  <devsnek>well I'm sure engines could do whatever optimization they wanted
21:43:14  <devsnek>bradleymeck: context is builtins that take numbers also taking bigints
21:47:12  * kaalchakkachanged nick to kaal_away
21:47:21  * kaal_awaychanged nick to kaalchakka
22:03:57  * kaalchakkaquit (Ping timeout: 245 seconds)
22:04:19  * mattijsjoined
22:05:38  * mattijsquit (Client Quit)
22:13:28  * bradleymeckquit (Quit: bradleymeck)
22:15:52  * bradleymeckjoined
22:17:40  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:18:49  * keith_millerjoined
22:44:35  * atticoosjoined
22:45:22  * atticoosquit (Client Quit)
22:46:45  * atticoosjoined
22:47:18  * atticoosquit (Client Quit)
22:49:05  * atticoosjoined
23:16:09  * mattijsjoined
23:21:48  * mattijschanged nick to mattijs[away]
23:23:33  * mattijs[away]quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:38:16  * mattijsjoined
23:40:28  <jschoi>I’d like to ask for feedback/criticism on an explainer and specification at https://github.com/js-choi/proposal-smart-pipelines/ and https://jschoi.org/18/es-smart-pipelines/spec.
23:41:09  <jschoi>In particular, I’d like to know whether their current organization is too confusing. There is a simple “actual” Core Proposal, plus several optional Additional Features that extend the Core Proposal and address several other use cases.
23:41:15  <jschoi>But the Additional Features are optional and mutually independent. I’ve currently integrated the Additional Features in the same documents as the Core Proposal because the Additional Features demonstrate the conceptual generality of the Core Proposal.
23:42:17  <jschoi>Thanks in advance to anyone. 👍🏻
23:43:17  <devsnek>wow
23:43:27  <devsnek>impressive document you put together here
23:44:17  <jschoi>Thanks, gosh. If the layout of the explainer is difficult to navigate by scrolling, there is a TOC in a details widget at the beginning.
23:44:30  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:45:07  <devsnek>i like it
23:45:17  <devsnek>there is some weirdness with github formatting though
23:45:41  <devsnek>oh you know what it is, code blocks and odd cells have the same color
23:45:57  <jschoi>Yeah, I really do wish that they were different colors.
23:47:31  <devsnek>topic style without topic reference may be bug prone but i don't think its worth a syntax error
23:47:54  <devsnek>some people like programming with side effects
23:51:00  <jschoi>devsnek: I’m having trouble picturing an example of that being useful. For side effects in the middle of a pipeline, you would do `… |> do { sideEffect(); # } |> …`.
23:51:10  <devsnek>no i meant like
23:51:15  <devsnek>throwing away the topic binding
23:51:18  <devsnek>for whatever reason
23:51:32  * keith_millerjoined
23:51:56  <bterlson>jschoi: this is amazing
23:52:12  <jschoi>devsnek: Yes, when you would wish to not use the result of the previous step in a pipeline?
23:52:17  <bterlson>readme.md is so good
23:52:19  <jschoi>bterlson: Thanks, gosh.
23:52:22  <bterlson>minus the table highlighting :-P
23:52:39  <bterlson>which also confused me momentarily
23:52:46  <devsnek>jschoi: i have no idea, i probably wouldn't ever do that
23:52:53  <devsnek>but i also wouldn't ever use lodash and people seem to do that
23:53:02  <jschoi>bterlson: Yeah. I should figure out where to complain to GitHub about that.
23:53:08  <devsnek>twitter
23:53:15  <jschoi>Heh.
23:53:38  <jschoi>I chose those libraries because they were the top used on NPM that I had time to get to.
23:53:44  * atticoosquit (Ping timeout: 260 seconds)
23:53:50  <devsnek>oh are there examples in here with libraries?
23:54:00  <devsnek>i'm about 1/6th of the way through
23:54:09  <jschoi>Yeah, real-world examples for each subproposal. They’re subsections.
23:54:12  <devsnek>ah ok
23:54:15  <devsnek>rn i'm looking at `value |> function () { return #; }`
23:54:18  <jschoi>First one is WHATWG Fetch’s spec examples.
23:54:33  <devsnek>so the topic binding doesn't get closure'd
23:54:37  <devsnek>is that what this example is showing?
23:54:43  <jschoi>It does get closured.
23:54:49  <devsnek>it says its a syntax error
23:54:53  <jschoi>Oh, wait.
23:54:54  <jschoi>I’m dumb.
23:54:59  <jschoi>I read it as an arrow function.
23:55:20  <devsnek>this and the below example with a class
23:55:24  <jschoi>Topic references are invalid inside function () { … }.
23:55:31  <jschoi>As well as most blocks.
23:55:41  <jschoi>Arrow functions, if blocks, and try blocks are exceptions.
23:55:50  <bterlson>jschoi: you tweet this yet? I need to retweet :-P
23:55:52  <jschoi>The intent is to make scoping always clear. That’s one of the goals.
23:56:14  <devsnek>man this is so detailed oof
23:56:25  <devsnek>ok i just hit the fetch example
23:56:47  <devsnek>i'm liking this so far
23:56:57  <jschoi>bterlson: Ah, I barely use Twitter. Go ahead. I’m at…@__jschoi.
23:57:39  <jschoi>Oh yeah, do blocks are also obviously exceptions. I say obviously because they’re in a lot of examples.
23:58:08  <jschoi>Another intent is to stay forward compatible with tacit topic binding by other types of blocks. Like catch blocks.
23:58:25  <jschoi>devsnek: Great, glad you like it so far.
23:58:38  <devsnek>i didn't know lodash was in the js foundation
23:58:48  <jschoi>Yeah, I hadn’t either until my research for this.
23:59:03  <devsnek>can i join the foundation and attend tc39 meetings 😢
23:59:08  * mattijs_joined
23:59:45  <jschoi>Let me know if you figure out the answer, haha.