00:06:48  * not-an-aardvarkquit (Ping timeout: 240 seconds)
00:07:15  * not-an-aardvarkjoined
00:18:21  * bradleymeckquit (Quit: )
00:41:57  * Fishrock123quit (Remote host closed the connection)
00:53:33  * cloudshujoined
01:17:02  * Fishrock123joined
01:22:32  * Fishrock123quit (Quit: Leaving...)
01:31:06  * AtumT_joined
01:34:16  * AtumTquit (Ping timeout: 255 seconds)
02:30:21  * AtumT_quit (Remote host closed the connection)
02:34:30  * howdoiquit (Quit: Connection closed for inactivity)
03:19:55  * srl295quit (Quit: Connection closed for inactivity)
04:12:21  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
06:15:46  * jmdyckquit (Remote host closed the connection)
08:55:40  * zjrjoined
08:55:40  * zjrquit (Client Quit)
09:09:48  * purujoined
09:10:38  * puruquit (Client Quit)
09:25:05  * AtumTjoined
10:30:37  * gibson042quit (Ping timeout: 252 seconds)
11:03:51  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
11:25:06  * mylesborinsquit (Quit: farewell for now)
11:25:37  * mylesborinsjoined
12:31:54  * ahnheejongjoined
12:39:28  * jmdyckjoined
12:43:56  * gibson042joined
12:53:26  * gibson042quit (Quit: Leaving.)
15:29:31  * ioctaptcebjoined
15:29:43  * ioctaptcebquit (Client Quit)
15:30:13  * ioctaptcebjoined
15:30:18  * ioctaptcebchanged nick to ystartsev
15:30:27  <ystartsev>hello!
15:30:34  * bradleymeckjoined
15:57:25  <bradleymeck>I had a bug in my example that I was walking through with spec. it isn't inconsistent, but it does seem the intrinsic `.then` works on Promises after Promise.prototype.then is deleted can work to get the resolution
15:57:38  <bradleymeck>however, it is somewhat particular in how you do it
15:57:58  <bradleymeck>`await` cannot get the resolution value that I can tell since it always defers to the "then"
16:09:02  * bdnuggerjoined
16:28:05  <bradleymeck>manual unboxing function... works https://jsbin.com/kaciyulilo/edit?js,console , but seems odd to need that to be safe, it is pretty heavy in cost to run
16:39:20  * injectJonjoined
17:00:57  * injectJonquit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
17:01:47  * injectJonjoined
17:17:35  * injectJonquit (Ping timeout: 255 seconds)
17:45:27  * caridyquit (Remote host closed the connection)
17:45:57  * caridyjoined
17:54:45  * bradleymeckquit (Read error: Connection reset by peer)
17:54:57  * bradleymeckjoined
18:33:27  * bradleymeckquit (Quit: bradleymeck)
18:33:31  * nosigiljoined
18:58:24  <nosigil>Is it possible to not to use sigils for private fields whatever it takes? for example, I guess babel compiler could be modified to store a list of a registered private field names for a class and replace every matched words (not properties, not strings) inside a method with weak map implementation of the private field, that way private properties would not need any special identification at all, only a ‘private fieldName’ declarat
18:58:52  <nosigil>Private fields of other instances of the same class could be accessed like that instanceFromArgumet->privateField.
18:59:38  * bradleymeckjoined
19:00:16  <ljharb>nosigil: babel can't prevent runtime reflection, and "private" means it's impossible for *anything in the runtime* to detect even the presence of a private field.
19:00:26  <ljharb>nosigil: https://github.com/tc39/proposal-private-fields/blob/master/FAQ.md might be helpful
19:37:13  <nosigil>thank you for the answer, but I don't understand how sigil helps with runtime. Does that mean that runtime itself would be able to resolve #x? Then why not to add some special closure for registered private properties or something like that? Hope I understood you correctly at least a bit :)
19:40:39  <ljharb>nosigil: the runtime comment was about "using babel to figure out what strings wouldn't collide"
19:48:48  * linclarkjoined
19:50:41  <tschneidereit>bterlson: can you voice linclark and invite her to the -delegates channel?
19:52:04  <tschneidereit>bterlson: same for ystartsev
20:05:55  * bradleymeckquit (Quit: bradleymeck)
20:37:55  * nosigilquit (Ping timeout: 260 seconds)
21:02:09  * AtumTquit (Ping timeout: 264 seconds)
21:09:14  * jwaldenjoined
21:12:27  * AtumTjoined
21:15:34  * AtumT_joined
21:19:18  * AtumTquit (Ping timeout: 268 seconds)
21:24:45  * bdnuggerquit (Quit: Connection closed for inactivity)
22:09:33  * bradleymeckjoined
22:31:05  * floatleftjoined
23:01:32  <bterlson>tschneidereit: linclark: ystartsev: done
23:01:37  <ystartsev>thanks!
23:03:26  <tschneidereit>bterlson: thank you!
23:10:49  * bdnuggerjoined
23:45:53  * bradleymeckquit (Quit: bradleymeck)
23:46:07  <bterlson>So, ChakraCore throws away all array mutations that occur while sorting
23:46:11  <bterlson>and no one has noticed
23:46:33  <ljharb>O.o
23:46:38  <bterlson>not entirely sure if it's allowed per spec tbh
23:46:45  <ljharb>bterlson: you mean like, mid-sort mutations?
23:46:48  <bterlson>but might be nice to codify our behavior since it's faster? ;)
23:46:49  <bterlson>yeah
23:46:50  <ljharb>or like assigned properties on the array
23:48:32  <bterlson>https://www.irccloud.com/pastebin/ZdbPxYX6/
23:48:45  <ljharb>wow
23:48:56  <ljharb>tbh i'm not even sure how that would be specified
23:49:12  <bterlson>it says that if your sort function does weird things then the sort order is implementation defined
23:49:21  <ljharb>i guess it would copy the array in memory, cache up all the comparisons, and then re-assign all of them?
23:49:27  <ljharb>is that observable? what if my array has a setter
23:49:30  <ljharb>or what if it's a Proxy
23:49:40  <ljharb>or what if it's a sparse array and Array.prototype has a setter?
23:50:16  <caridy>oh! yeah! we came across this one when implementing proxy compat for IE11 :)
23:50:41  <caridy>`sort` is kinda weird!
23:50:42  <tschneidereit>pretty sure that behavior doesn't strictly fall under "sort order" :)
23:50:51  <ljharb>sort is super weird and i'm firmly in favor of locking it down
23:51:12  <ljharb>but that particular semantic seems fairly impossible to spec, and fairly likely that it'll not be web compatible even if there's been no edge bug reports :-/
23:52:05  <bterlson>tschneidereit: yeah :-P
23:52:41  <bterlson>so anyone want to copy this or should I slow down our sort and fix the bug...
23:53:25  <bterlson>ljharb: to answer your question, all observable things are still observable
23:53:50  <ljharb>lol that tautology doesn't really answer my question
23:54:03  <bterlson>proxy, getter, etc.
23:54:13  <bterlson>it's like while sorting you're working on a copy I guess?
23:54:32  <ljharb>but i don't have to be working on a real array either
23:54:39  <ljharb>it could be an arraylike object
23:54:59  * tschneidereitbets this only happens for dense arrays
23:56:25  <tschneidereit>or, hmm. Maybe not
23:57:05  <tschneidereit>eh, anyway. I agree with ljharb - these semantics seem exceedingly weird and I doubt they're web compatible in the long tail
23:57:28  <bterlson>you're saying our telemetry is broken??
23:57:32  <ljharb>lol
23:57:45  <ljharb>again tho, any way we can lock down `sort` is fine by me, "implementation-dependent" is icky
23:57:57  <bterlson>according to Caridy it's been that way since IE11
23:58:01  <bterlson>it's possibly been that way since IE9
23:58:08  <tschneidereit>oooh, can we make it stable?
23:58:28  <littledan>do you really want it to be stable? that could slow down existing websites
23:58:37  <tschneidereit>it's stable in SM
23:59:03  <littledan>what do other JS implementations do?
23:59:18  <littledan>if it's stable in almost all of them...
23:59:32  <tschneidereit>bterlson: well, maybe it is compatible - who knows. The semantics still don't make much sense :P
23:59:37  <tschneidereit>v8 is unstable
23:59:56  <tschneidereit>that's all I remember. It's been a few years since I worked on this