00:33:22  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
00:48:48  * bradleymeckjoined
01:43:10  * darkSeid_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:10:48  * marxo_quit (Ping timeout: 272 seconds)
02:32:40  * mylesborinsquit (*.net *.split)
02:32:40  * ChanServquit (*.net *.split)
02:33:58  * howdoiquit (Quit: Connection closed for inactivity)
02:34:39  * ChanServjoined
02:36:17  * mylesborinsjoined
02:39:13  * gibson042joined
03:03:48  * gibson042quit (Read error: Connection reset by peer)
03:06:37  * gibson042joined
03:23:00  * gibson042quit (Ping timeout: 272 seconds)
04:13:39  * bradleymeckquit (Quit: bradleymeck)
04:38:29  * not-an-aardvarkjoined
04:40:32  * jmdyckquit (Remote host closed the connection)
05:28:30  * caridyjoined
05:29:41  * caridy__quit (Read error: Connection reset by peer)
05:38:51  * caridyquit (Remote host closed the connection)
05:42:21  * Emulousjoined
05:47:01  <Emulous>Has any thought been given to some pleasant syntactic sugar like `Object.typeOf()` to get `null` returning "null" (and, perhaps depending on a second argument of options, `Array` instances returning "array" and/or constructors/class instances returning their class name)--with behavior otherwise like "typeof"?
06:01:33  * Emulousquit (Ping timeout: 264 seconds)
06:03:25  * howdoijoined
06:07:23  * caridyjoined
06:07:27  * caridyquit (Remote host closed the connection)
06:07:35  * caridyjoined
06:07:44  * caridyquit (Remote host closed the connection)
06:16:05  * Draggorquit (Ping timeout: 240 seconds)
06:18:09  * Draggorjoined
06:57:58  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
07:08:06  * caridyjoined
07:12:09  * caridyquit (Ping timeout: 240 seconds)
07:30:42  * Havvyjoined
07:34:37  * darkSeid_joined
07:54:21  * darkSeid_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:30:20  * Emulousjoined
08:47:16  * Emulousquit (Ping timeout: 272 seconds)
09:05:45  * Emulousjoined
09:10:25  * caridyjoined
09:14:27  * caridyquit (Ping timeout: 240 seconds)
09:58:22  * marxojoined
11:07:04  * marxo_joined
11:11:01  * marxoquit (Ping timeout: 260 seconds)
11:12:01  * caridyjoined
11:14:39  * marxo_quit (Ping timeout: 248 seconds)
11:16:21  * caridyquit (Ping timeout: 256 seconds)
11:25:07  * mylesborinsquit (Quit: farewell for now)
11:25:38  * mylesborinsjoined
12:46:12  * jmdyckjoined
13:02:29  * bradleymeckjoined
13:15:01  * bradleymeckquit (Quit: bradleymeck)
13:23:42  * marxojoined
13:48:44  * Emulousquit (Ping timeout: 272 seconds)
13:58:35  * marxo_joined
14:01:52  * marxoquit (Ping timeout: 268 seconds)
14:10:27  * gibson042joined
14:12:20  * bradleymeckjoined
14:38:57  * spectranautquit (Quit: No Ping reply in 180 seconds.)
14:39:40  * caridyjoined
14:40:04  * spectranautjoined
14:44:17  * caridyquit (Ping timeout: 248 seconds)
15:06:47  * Emulousjoined
15:56:16  * Emulousquit (Ping timeout: 260 seconds)
16:16:35  * AtumTjoined
16:35:55  * jwaldenjoined
16:42:51  * bradleymeckquit (Quit: bradleymeck)
16:47:10  * caridyjoined
16:47:40  * caridyquit (Remote host closed the connection)
16:48:12  * caridyjoined
17:41:20  * marxo_quit (Ping timeout: 248 seconds)
17:53:44  * bradleymeckjoined
18:26:28  * caridyquit (Ping timeout: 240 seconds)
18:27:51  * caridyjoined
18:28:32  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
19:05:57  * darkSeid_joined
19:06:04  * AtumTquit (Read error: Connection reset by peer)
19:07:25  * AtumTjoined
19:19:11  * AtumT_joined
19:19:45  * AtumTquit (Read error: Connection reset by peer)
19:50:24  * caridyquit (Ping timeout: 248 seconds)
19:52:55  <Domenic>I'm thinking of preparing a proposal to censor Function.prototype.toString in a per-function opt-in manner. Do people have any ideas on the API? So far I have (a) a new pragma e.g. 'use no Function.prototype.toString'; and (b) a symbol e.g. fn[Symbol.noFunctionToString] = true
19:53:21  <Domenic>aklein: ^
19:53:41  <bradleymeck>please no on the symbol
19:54:04  <bradleymeck>is there ever a time that a function wants to go from censored to public?
19:54:20  <annevk>What's the motivation for this? So you can do what the platform does?
19:54:51  <Domenic>That, and memory usage, and encapsulation
19:55:16  <Domenic>bradleymeck: I wasn't envisioning enabling un-censoring; fair point.
19:57:15  <aklein>Domenic: uncensoring shouldn't be supported if we want to allow memory optimization. I have to admit I was imagining something outside the language, a la CSP
19:57:35  <Domenic>Hmmm interesting
19:57:47  <Domenic>I guess the question is scope; CSP would be whole page scoped
19:59:41  * not-an-aardvarkjoined
20:00:16  <aklein>For engines I think it might be useful to know per resource, which I guess is more fine-grained...and I guess a downside of CSP-like is that you also get the CSP-y problem of libraries needing to deal with being loaded into such an environment
20:00:51  <aklein>if you want per-function the pragma seems like the right place to start, as ugly as it is
20:05:57  * jwaldenjoined
20:06:09  <ljharb>Domenic: if a pragma, why not a keyword?
20:06:19  <ljharb>Domenic: `secret function () {}` or something
20:06:22  <Domenic>ljharb: backward compat
20:06:30  <ljharb>ah, true
20:06:46  <Domenic>Also you could then do it per source file
20:06:49  <ljharb>seems like there'd be pushback on more pragmas, but maybe it's fine for this case
20:13:54  <Domenic>yeah, i'm unsure.
20:19:49  <ljharb>would that impact stack traces (line numbers specifically), or be unrelated?
20:21:19  <cloudshu>Domenic: i am in favor of such censorship
20:22:28  <cloudshu>also agreed on that censorship will be a 1-way switch
20:22:32  <cloudshu>or, should be
20:23:24  <cloudshu>i'm having trouble imagining where this censorship is desired on a per-function granularity though
20:23:41  <ljharb>it definitely feels like it needs to be tied to the source text, just like the toString output is, and not runtime-changeable in either direction
20:23:57  <Domenic>Yeah, I think I'm abandoning the symbol idea; good thing I asked this channel
20:24:11  <Domenic>I think this would impact line numbers in the same way that C++ functions currently do. (I'm not sure what that is.)
20:24:38  <ljharb>whatever the impact, it'd need to integrate with the stacks proposal (if not the current one, the followon ones mark wants to do)
20:24:42  <Domenic>cloudshu: I agree per-function might not be useful. Per source file is useful though, as opposed to whole-web-page.
20:24:49  <Domenic>ljharb: agreed.
20:24:59  <ljharb>and you want it to work on Scripts too, not just Modules?
20:25:19  <cloudshu>Domenic: yeah, agreed
20:25:42  <ljharb>also would i be able to runtime-distinguish native functions, from non-native censored functions?
20:25:59  <cloudshu>ljharb: wait, why would line numbers be impacted by discarding source?
20:26:15  <ljharb>cloudshu: if the source text is censored, and a stack trace still points to a line number within it, that might be an issue
20:26:32  <cloudshu>ljharb: i'm not understanding in what way
20:26:43  <ljharb>off the top of my head i'm not sure either
20:26:57  <ljharb>i've only had 20 minutes to think about toString censorship :-p
20:27:00  <ljharb>i'm just anticipating an interaction
20:27:01  <cloudshu>ljharb: "censorship" here is just that toString() returns some fixed string "[no source]" or whatever, right?
20:27:08  <cloudshu>not any additional censorship
20:27:45  <ljharb>i assume so. but toString serves as a quasi-toSource atm, so despite the committee's preference to avoid toSource, there still might be interesting interactions to consider
20:27:50  <ljharb>source maps, for example
20:28:04  <ljharb>the debugger having superpowers to see into censored source
20:28:27  <cloudshu>debuggers most definitely do not use toString to do source mapping
20:28:30  <ljharb>well yeah
20:28:48  <ljharb>but would it be surprising or desirable for a dev using a debugger to be able to see censored function source
20:28:52  <cloudshu>i am skeptical on line numbers being an issue -- toString for a long time in SM didn't even return the original string
20:28:58  <ljharb>it very well might be the case that everything i've mentioned as a possible pitfall is a non-issue. i'm just spitballing :-)
20:29:26  <cloudshu>ljharb: maybe it's because "censorship" has very wide connotation
20:30:09  <Domenic>ljharb: I don't think we'd want to have them be distinguishable? But you get the benefits even if they are, so if there's some reason, then we could do it.
20:30:57  <ljharb>Domenic: lodash for example has a lot of pivots on "is this function native or not", for better or worse
20:33:17  <cloudshu>Domenic: well, they're necessarily distinguishable if they return a fixed string in actual impls
20:33:29  <cloudshu>if their toString, that is
20:33:38  <Domenic>ljharb: sure, the question is, do we want lodash to detect these censored things as native or not.
20:34:08  <Domenic>cloudshu: if this version makes it return `function foo() { [native code] }` then they're not
20:34:18  <cloudshu>Domenic: ah ha, i see
20:34:44  <cloudshu>i have vague misgivings about giving users ability to masquerade their functions as native code
20:35:20  <cloudshu>wait, they can easily enough do this now, i guess
20:38:39  <ljharb>cloudshu: no they can't
20:39:12  <ljharb>cloudshu: `Function.prototype.toString.call()` with a cached/known-good Function.prototype.toString will only ever return the native code thing for real native functions
20:41:34  * caridyjoined
20:55:38  <cloudshu>ljharb: ah ok, are most frameworks doing that?
20:56:11  <cloudshu>in any case, then my misgivings stand
21:04:48  * caridyquit (Ping timeout: 240 seconds)
21:07:35  <Bakkot>It is already possible to do per-function hiding of .toString by overwriting F.p.toString, but it's somewhat tricky to do well since you also have to overwrite it in new realms
21:08:06  <Bakkot>(if you run first of course)
21:09:03  <Bakkot>anyone who is serious about detecting nativeness is using a cached F.p.toString, though, yes
21:12:57  <Bakkot>Domenic: a possible API would be a method on Function.prototype like .bind
21:13:15  <Domenic>Ah, not bad.
21:13:39  <Bakkot>(.bind already accomplishes this, in fact, but with other effects you probably don't want.)
21:14:58  <Bakkot>'.sourceless()', maybe?
21:15:23  <cloudshu>.noString()
21:17:47  <Bakkot>I guess there's two possibilities for how such a method could work - changing the behavior of F.p.toString for its receiver, or giving you a new function with the same behavior except for F.p.toString.
21:17:50  <Bakkot>would strongly prefer the latter.
21:18:16  <Domenic>Hmm, but all those problems with homeobject copying etc...
21:18:23  <Bakkot>would require more work from enginges to get the memory usage benefits, but I think it would be a lot nicer.
21:20:10  <cloudshu>and identity issues
21:20:39  <Bakkot>I would expect the common pattern to be (function literal).sourceless(), in which case it really wouldn't matter.
21:26:15  <Domenic>How do you do that for methods though
21:26:18  <Domenic>And classes
21:26:26  <Domenic>Leaning back toward directive.
21:26:30  <Bakkot>Mm, fair, hadn't considered those.
21:26:44  <Bakkot>Works fine for classes, but not so much for methods.
21:29:06  <cloudshu>Reflect.sourceless(thing)?
21:29:28  <cloudshu>i still want noString though
21:30:48  * darkSeid_quit (Quit: Textual IRC Client: www.textualapp.com)
21:31:16  <Bakkot>I increasingly just want to start all my programs with `delete Function.prototype.toString;`
21:32:29  * darkSeid_joined
21:40:28  <ljharb>could you do it on methods with a decorator?
21:40:44  <ljharb>ie, `.sourceless()` or whatever for the normal case, and a decorator just does that replacement for you
21:40:54  <ljharb>(such that `f !== f.sourceless()`, just like .bind)
21:41:37  <Bakkot>decorators for methods in object literals aren't even a proposal at the moment, IIRC
21:42:16  <ljharb>sure, but absent a way to observe [[HomeObject]], are methods in object literals anything more than concise syntax at the moment? :-)
21:42:36  <ljharb>you're right tho that either way we'd want a decorator to work for that :-/
21:43:47  <Bakkot>I do think a new prototype method would have a much higher chance of making it through committee
21:43:50  <Bakkot>syntax is expensive
21:44:53  <ljharb>prototype methods aren't syntax
21:44:57  <ljharb>but sure, `Reflect.sourceless()` or similar is fine
21:45:11  <ljharb>(altho we'd need a different namespace, since Reflect is just for proxy traps iirc)
22:06:21  <Domenic>I'm glad that me saying that over and over (about Reflect) seems to have finally stuck :)
22:06:48  <Domenic>Bakkot: do you think directives are as expensive as syntax?
22:07:12  <Bakkot>ljharb: right, that's my point
22:07:16  <Bakkot>Domenic: uhhh approximately yes.
22:07:20  <Bakkot>they are syntax.
22:07:51  <Bakkot>Not as much as, say, `match`, but still way more than a new prototype method.
22:08:14  <ljharb>Domenic: lol what should the different namespace be called tho? some have suggested "System" ᕕ( ᐛ )ᕗ
22:08:39  <ljharb>(inb4 response: just put it on Function)
22:13:15  * caridyjoined
22:13:32  * caridyquit (Remote host closed the connection)
22:14:08  * caridyjoined
22:17:40  * ChanServquit (*.net *.split)
22:22:35  <aklein>does anyone of know a previous attempt to introduce async JSON parsing/serialization (the latter is a bit trickier, I know)? I see plenty of chatter about the lack of it on the interwebs, but nothing TC39/es-discuss related
22:23:04  <ljharb>aklein: i'm pretty sure it's been on esdiscuss, one sec
22:23:31  <aklein>ljharb: ah, so there is, didn't poke specifically enough there
22:23:50  <ljharb>https://esdiscuss.org/topic/please-help-with-writing-spec-for-async-json-apis
22:24:22  * ChanServjoined
22:25:43  * Emulousjoined
22:25:52  <aklein>ljharb: thanks! reading through that thread now...doesn't sound like this may have ever gotten behind es-discuss though
22:26:06  <ljharb>behind?
22:27:03  <ljharb>i think it died there tho; seems like it's worth a stage 0 at least
22:27:03  <aklein>*beyond
22:28:57  * ChanServquit (*.net *.split)
22:31:45  * ChanServjoined
22:31:59  * Emulousquit (Ping timeout: 248 seconds)
22:32:14  * Emulousjoined
22:45:51  * Emulousquit (Ping timeout: 248 seconds)
22:50:01  * caridy_joined
22:50:08  * caridyquit (Ping timeout: 240 seconds)
23:03:33  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
23:43:50  * Emulousjoined
23:52:30  * caridy_quit (Remote host closed the connection)
23:55:57  <Emulous>Has any thought been given to some pleasant syntactic sugar like `Object.typeOf()` to get `null` returning "null" (and, perhaps depending on a second argument of options, `Array` instances returning "array" and/or constructors/class instances returning their class name)--with behavior otherwise like "typeof"?
23:56:50  <bradleymeck>Emulous: why does it need to be syntax?
23:57:20  <bradleymeck>do you just mean an API?
23:57:35  <Emulous>ah yes, sorry, just an API
23:57:48  <Emulous>lexical sugar :)
23:59:03  <bradleymeck>it has been looked at many times, I just haven't seen it make much progress. Symbol.toStringTag kind of does what you want
23:59:36  <bradleymeck>that + Object.prototype.toString.call(value)