00:08:13  * not-an-aardvarkjoined
00:33:00  * bradleymeckquit (Quit: bradleymeck)
00:35:12  * srl295quit (Quit: Connection closed for inactivity)
00:54:41  * AtumTquit (Remote host closed the connection)
01:34:10  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
01:51:44  * araiquit (Ping timeout: 276 seconds)
02:17:53  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
03:12:31  * araijoined
03:14:38  * vladi-devjoined
03:21:45  <vladi-dev>hello everyone, i'd like to get some feedback about my proposal to JS syntax. Coming from Python I found that in JS import syntax is not very well suited for IDE's to hint variable/function names that you can import. Basically my proposal is to reverse the keywords in the import statement like so `from 'foo' import { bar}` so that IDE can show me which exports are available in module 'foo'. Please take a look and let me know your th
03:21:53  <vladi-dev>https://github.com/vladi-dev/proposal-reverse-import-syntax
04:08:26  <ljharb>vladi-dev: `import` is reserved, but `from` is not - i'm not sure it's feasible.
04:09:14  <ljharb>vladi-dev: have you looked into https://www.npmjs.com/package/import-js, which lets your IDE do autocompletion with the current syntax?
04:17:33  <vladi-dev>ljharb: i created a proof of concept that parses the proposed syntax(https://github.com/vladi-dev/babel/pull/1/files#diff-ceab643e717dca7190cd479a5fabdb1dR8), i know it can be done in a nicer way but im exporing if it is worth the effort. and yes i saw `import-js` plugin but it is not as convenient as it can be (like in Python). thank you for feedback!
04:19:25  <ljharb>what about side-effecting imports? would they be `from 'foo' import;`?
04:29:33  * jmdyck1quit (Remote host closed the connection)
04:31:19  * vladi-devquit (Ping timeout: 260 seconds)
04:36:48  * not-an-aardvarkjoined
07:01:44  * araiquit (Remote host closed the connection)
09:08:06  * araijoined
09:08:21  * araiquit (Remote host closed the connection)
10:25:09  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
11:16:31  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
13:19:34  * bradleymeckjoined
13:29:58  * bradleymeckquit (Quit: bradleymeck)
13:30:49  * jmdyckjoined
13:31:20  * bradleymeckjoined
14:02:40  * mmunquit (Quit: ~)
14:02:52  * mmunjoined
14:05:29  * Domenicquit (Quit: ~)
14:05:45  * Domenicjoined
14:07:06  * TabAtkinsquit (Quit: ~)
14:07:18  * TabAtkinsjoined
14:07:52  * d_runquit (Quit: ~)
14:08:05  * d_runjoined
14:09:12  * samthquit (Quit: ~)
14:09:23  * samthjoined
14:11:54  * bterlsonquit (Quit: ~)
14:12:06  * bterlsonjoined
14:13:53  * bstoroz_quit (Quit: ~)
14:14:01  * bstoroz_joined
14:15:34  * jackhortonquit (Quit: Connection closed for inactivity)
14:16:54  * srl295joined
14:19:42  * fletquit (Quit: ~)
14:19:47  * plumaquit (Quit: ~)
14:19:54  * fletjoined
14:19:59  * plumajoined
14:25:54  * domfarolinoquit (Quit: ~)
14:26:06  * domfarolinojoined
14:27:12  * diervoquit (Quit: ~)
14:27:21  * diervojoined
14:29:36  * rkirslingquit (Quit: ~)
14:29:48  * rkirslingjoined
14:31:57  * joyeequit (Quit: ~)
14:32:09  * joyeejoined
14:33:01  * thejameskylequit (Quit: ~)
14:33:13  * thejameskylejoined
14:33:20  * Wizekquit (Quit: ~)
14:33:21  * gsathyaquit (Quit: ~)
14:33:25  * maggiepint_quit (Quit: ~)
14:33:33  * gsathyajoined
14:33:41  * maggiepint_joined
14:34:00  * Wizekjoined
14:37:08  * jschoiquit (Quit: ~)
14:37:17  * jschoijoined
15:22:32  <bradleymeck>https://github.com/drufball/layered-apis/issues/6 seems interesting, still hard to use the API, but if it can't be forged that at least gives some easier times
15:28:29  <devsnek>layered APIs are pretty interesting
15:30:55  <bradleymeck>devsnek: I'm still wanting a usability fix for some things though. using arrays is almost always taintable and I'm not clear on how to make that better. making {0: 'value for 0', length: 1} in all the places is a goofy workaround.
15:32:56  <devsnek>for issue #6 it sounds like you would have to somehow identify a polyfill as official and host its access to primordials
15:33:02  <devsnek>or let everything access them
15:42:04  <bradleymeck>devsnek: the intent here is something that cannot be added to by userspace
15:42:30  <bradleymeck>you can polyfill it / I just posted one, but people could check if something is a polyfill is part of the value
16:10:28  * bradleymeckpart
16:15:53  * jwaldenjoined
16:30:54  <devsnek>bradleymeck: I guess I'm misunderstanding then, the examples all appear to have CDN fallbacks so
16:42:14  * bradleymeckjoined
16:42:35  * bradleymeckquit (Client Quit)
16:46:05  * bradleymeckjoined
16:47:05  <bradleymeck>devsnek: LayeredAPIs is a bunch of things, part of that is allowing more reliable polyfills but also just how make the platform better in terms of being robust and having low level primitives
16:47:30  <devsnek>ic
17:03:34  * bradleymeckquit (Quit: bradleymeck)
17:16:31  * jmdyckquit (Ping timeout: 265 seconds)
17:17:19  * jmdyckjoined
17:41:20  <devsnek>does michael ficarra ever come on irc
17:55:10  <ljharb>yes! but i only reliably remember seeing him on during the meetings he's present at
18:41:42  <devsnek>ljharb: i'm curious about how his protocol proposal can be an alternative to my proposal
18:44:32  <devsnek>Promise.Thenable protocol with a "disabled" symbol or something similar
19:04:55  * bradleymeckjoined
19:09:32  <ljharb>devsnek: that would totally work, but the part your proposal that's "making ModuleRecords not thenable" is super time-sensitive, so i don't think it can wait on the protocols proposal. it's also possible (i believe) to make an existing symbol be part of a protocol later, so we could later add a "Thenable" protocol that used Symbol.thenable or whatever, if it came to that
19:15:56  <devsnek>ljharb: if people are willing to go forward with that it sounds great
19:18:10  <devsnek>I'm just worried about push-back on yet another symbol modifying behaviour
19:18:29  * bradleymeckquit (Quit: bradleymeck)
19:19:48  * JaseWjoined
19:21:00  * bradleymeckjoined
20:01:06  <ljharb>devsnek: pushback on the symbol is one thing; but the whole motivation of the proposal really seems like Module Records, and it can't go on those if it ends up being web-incompatible to change
20:01:53  <devsnek>that is definitely the motivation of the proposal
20:02:12  <devsnek>I wish I had gotten involved with this like 9 months ago
20:02:32  <Bakkot>dynamic import isn't even stage 4; surely changing the thenable behavior of module imports can't be web-incompatible at this stage?
20:02:35  <ljharb>to be fair, the question was raised awhile back and i'm relatively sure that this is the desired behavior
20:02:45  <ljharb>Bakkot: `import * as foo from 'path'; Promise.resolve(foo)`
20:02:57  <ljharb>(where "this" is "the current behavior")
20:03:09  <ljharb>but i'd still like to see it change
20:03:11  <Bakkot>ljharb: sure; just don't think that's a very likely use, whereas `await import('path')` seems much more
20:03:17  <ljharb>true
20:03:40  <Bakkot>devsnek: can't really read scrollback to see if this has been mentioned, but see https://github.com/tc39/proposal-dynamic-import/issues/47 / https://github.com/tc39/proposal-dynamic-import/issues/48 if you haven't
20:06:25  <devsnek>yeah I saw those
20:06:56  <devsnek>which is why I tried to make my solution as general as possible
20:07:17  <devsnek>s/general/generalised/
20:09:29  <ljharb>tbh i think your solution is fine; i'm just not optimistic it will be well-received, but i also don't know what you could do to improve the chances :-/ it's still worth proposing tho
20:13:12  <devsnek>I'll add some notes to the readme about futurey stuff like protocols and whatnot and then I guess in terms of stage-0ness it's probably good to go
20:13:52  <devsnek>tbh the thing I'm most worried about is my ecmarkup-fu :p
20:24:00  <ljharb>that doesn't matter til stage 2 :-p
20:30:56  <Bakkot>unrelated: anyone know the justification for `new class A extends B { constructor(){ super(); super(); }` calling `B` a second time before erroring out, rather than erroring out before calling `B`?
20:31:08  <Bakkot>that behavior is weird.
20:31:34  <bterlson>bakkot: I raised this at one point during ES6 I think? It'll be in the notes. Allen had some justification.
20:31:41  <bterlson>I don't remember it
20:32:38  <Bakkot>The closest thing I can think of is, you do have to do argument list evaluation before throwing, so maybe it's weird to not then go through with the call.
20:32:42  <Bakkot>I'll try to dig it up in the notes.
20:32:56  <bterlson>Bakkot: I'd try like 2015 to start with
20:33:36  <Bakkot>ah: https://github.com/rwaldron/tc39-notes/blob/61dc2f45829a0663af0b4b1d6690717dc70d30d9/es7/2017-01/jan-24.md#discussing-not-calling-super-multiple-times
20:34:23  <bterlson>wow
20:34:26  <bterlson>I was way off on the time lol
20:34:31  <Bakkot>lol, I have commented on the relevant PR with an example I'd forgotten about
20:37:44  <bterlson>I'm re-angry about this so thanks Bakkot
20:38:44  <Bakkot>the thing where you can leak a `super()` via an arrow is still baffling to me
20:39:05  <ljharb>i definitely agree that `super()` should throw *instantly* when the `this` has been previously bound
20:39:20  <Bakkot>like, who wanted that? it causes so much pain
20:39:40  <bterlson>I recall broad support for that
20:40:00  <bterlson>"super is like this in arrows" was a compelling argument?
20:41:18  <Bakkot>yeah, but... `let foo; try { new class extends Object { constructor(){ foo = () => super(); } m(){ return 42; } } } catch (e) { } foo().m(); // gives 42`
20:41:21  <Bakkot>like, that's terrible
20:43:56  <devsnek>weeeeeew
22:18:42  * bradleymeckquit (Quit: bradleymeck)
23:06:07  * bradleymeckjoined
23:49:42  * bradleymeckquit (Quit: bradleymeck)