00:06:59  * bradleymeckquit (Quit: bradleymeck)
00:17:06  * bradleymeckjoined
00:22:57  * bradleymeckquit (Quit: bradleymeck)
00:35:17  * AtumTquit (Remote host closed the connection)
00:49:34  <Bakkot>... anyone know why proxies don't pass through internal slots they lack? that they don't is... weird.
00:50:04  <Bakkot>and sort of hacked around in some places but not others: `Array.isArray(new Proxy([], {}))` is true, but `(new Proxy(new Number(0), {})) + 1` throws a TypeError.
00:53:11  <aklein>are there any places other than Array.isArray()? I guess 'typeof' makes it clear whether a Proxy is wrapping a Function...
00:53:37  * Fishrock123joined
00:55:22  * M-IvanSanchezquit (Ping timeout: 276 seconds)
00:55:41  * M-IvanSanchezjoined
00:59:48  <Bakkot>The proxy constructor copies [[call]] and [[construct]] over, is the other special casing, so you can call them and `typeof new Proxy(function(){}, {}) === 'function'` holds
01:03:39  <Bakkot>also, lol: anyone care to guess what `typeof new Proxy(document.all, {})` is?
01:09:05  * Fishrock123quit (Remote host closed the connection)
01:10:53  * not-an-aardvarkjoined
01:13:13  * Fishrock123joined
01:13:21  * Fishrock123quit (Remote host closed the connection)
01:14:00  * Fishrock123joined
01:14:06  * Fishrock123quit (Remote host closed the connection)
01:36:03  * bradleymeckjoined
02:07:15  <bterlson>jeffmo: thanks for the ping, I forgot about that issue. I'll merge it when back at work next week.
02:34:10  * bradleymeckquit (Quit: bradleymeck)
02:35:13  <bterlson>jeffmo: actually I lied, did it now
02:36:24  <jeffmo>Oh awesome, thanks!
02:38:29  * Fishrock123joined
02:43:16  * Fishrock123quit (Ping timeout: 276 seconds)
04:36:02  * howdoijoined
04:58:57  <jmdyck>That commit erased some early errors that I don't think it should have.
04:59:26  <bterlson>jmdyck: I think they're now limited in the grammar
04:59:58  <bterlson>eg. HexDigits [> but not if MV of HexDigits > 0x10FFFF ]?
05:00:03  <jmdyck>It is a Syntax Error if the number of elements in the result of TemplateStrings of |TemplateLiteral| with argument *false* is greater than 2<sup>32</sup>-1.
05:00:14  <jmdyck>It is a Syntax Error if _NcapturingParens_ ≥ 2<sup>32</sup>-1.
05:00:58  <bterlson>ahh hmm
05:02:29  <jmdyck>Also a bunch of other things, but I'm committing fixes for them.
05:02:41  <bterlson>jmdyck: a bunch?!?
05:03:46  <jmdyck>yup
05:04:06  <bterlson>I guess I shouldn't be accepting PRs while giving a talk :-P
05:04:30  <jmdyck>not removed things, but editorial things
05:06:46  <jmdyck>last 4 commits in https://github.com/tc39/ecma262/pull/964
05:07:07  <bterlson>jmdyck: looking deeper I'm not sure why those early errors were removed, they are not in the proposal
05:07:15  <bterlson>or in the notes of differences from the proposal
05:07:43  <jmdyck>maybe it didn't get rebased properly before merge
05:08:36  <bterlson>jmdyck: confirm
05:08:42  <bterlson>jmdyck: all my fault :'(
05:08:51  <bterlson>git revert -p time I guess
05:09:17  <jmdyck>those early errors were adjacent to ones which *were* supposed to be removed
05:09:26  <bterlson>yeah
05:09:36  <jmdyck>so too close in the diff
05:11:42  <jmdyck>do you want me to add a commit to reinstate them, or is that your penance?
05:12:27  <bterlson>I am currently self flagellating whilst reinstating them.
05:12:51  <jmdyck>don't multitask! that's what got you into this mess
05:13:20  <jmdyck>reinstate first, flagellate later.
05:13:33  <bterlson>ok fair
05:14:09  <bterlson>I'll look in to some kind of Johnny5 flagellation automation solution for the future (cc rwaldron)
05:15:16  <jmdyck>so do you do the reinstate as a fixup, or is that 'dangerous'
05:15:18  <jmdyck>?
05:15:55  <jmdyck>('fixup' in the sense of git rebase)
05:16:11  <bterlson>it'll just be a normal normative commit
05:16:17  <jmdyck>k
05:18:57  <jmdyck>gnight
05:19:42  <bterlson>jmdyck: thank you sir
05:19:48  <jmdyck>yw
05:20:32  * jmdyckquit (Quit: Leaving.)
05:23:35  * gskachkovquit (Quit: gskachkov)
06:58:05  * gskachkovjoined
07:03:57  * gibson042quit (Quit: Leaving.)
07:39:16  * tobiequit (Ping timeout: 255 seconds)
07:41:31  * tobiejoined
08:11:32  * TabAtkinsquit (Ping timeout: 255 seconds)
08:12:34  * TabAtkinsjoined
08:16:35  * gkatsevquit (Ping timeout: 240 seconds)
08:17:33  * gkatsevjoined
10:05:33  * caridy_joined
10:05:33  * caridyquit (Remote host closed the connection)
10:15:24  * AtumTjoined
10:25:33  * mylesborinsquit (Quit: farewell for now)
10:26:04  * mylesborinsjoined
11:00:30  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
11:53:21  * jmdyckjoined
12:46:08  * caridy_quit (Remote host closed the connection)
12:46:40  * caridyjoined
13:21:10  * howdoiquit (Quit: Connection closed for inactivity)
13:25:37  * bradleymeckjoined
13:43:52  * bradleymeckquit (Quit: bradleymeck)
14:01:44  * bradleymeckjoined
14:35:34  * gskachkovquit (Quit: gskachkov)
14:35:40  <jmdyck>bterlson: Also I notice that id="sec-primary-expression-template-literals-static-semantics-early-errors" got changed to id="sec-static-semantics-template-early-errors". There's no internal xrefs to it, but should we be concerned about possible external links?
14:36:23  * gskachkovjoined
14:36:23  * gskachkovquit (Client Quit)
15:35:42  * gskachkovjoined
15:47:21  * gskachkovquit (Quit: gskachkov)
16:07:04  * gskachkovjoined
16:21:30  * bradleymeckquit (Quit: bradleymeck)
16:49:53  * bradleymeckjoined
16:54:49  * Fishrock123joined
17:00:34  * caridyquit
17:03:31  * caridyjoined
17:04:02  <ljharb>jmdyck: we could add an extra `<a name="sec-primary-expression-template-literals-static-semantics-early-errors"></a>` to preserve the link
17:05:25  <jmdyck>we could.
17:05:44  <jmdyck>(Or we could just change it back.)
17:06:14  <ljharb>presumably the new ID reflects the correct location in the spec tho
17:06:39  <jmdyck>it's the same location
17:07:20  * caridyquit (Remote host closed the connection)
17:07:53  * caridyjoined
17:10:04  * howdoijoined
17:10:06  <jmdyck>plus, the new id doesn't follow the sec naming convention. (Not that I like that convention, but I didn't think we were at liberty to not follow it.)
17:12:41  <jmdyck>It occurred to me that maybe we should add an attribute 'oldids' for preserving old ids, and then ecmarkup could take care of generating the back-compat anchors.
17:35:56  * gskachkovquit (Quit: gskachkov)
17:55:00  * gskachkovjoined
19:04:56  * leobalterquit (Quit: Changing server)
19:09:21  * leobalte_joined
19:18:30  * leobalte_quit (Quit: Using Textual IRC Client)
19:18:43  * leobalter___joined
19:19:08  * leobalter___changed nick to leobalter
19:20:51  * leobalterquit (Client Quit)
19:24:10  * Guest78693joined
19:24:28  * Guest78693changed nick to leobalter
20:14:56  * Fishrock123quit (Remote host closed the connection)
20:19:54  <jeffmo>littledan: Can you remind me why there is a restriction on name-sharing between private instance and static fields? I know we sort of discovered that it would impede some design decisions down the road with shorthand syntax... Is that the only reason?
20:21:46  <bradleymeck>jeffmo: was there a design for grabbing them w/o shorthand off the containing class?
20:22:50  <jeffmo>bradleymeck: when we had shorthand included, the previous spec text stated that `#foo` was strictly sugar for `this.#foo`. So in a static method, `this` is a ref to the class object
20:24:43  <jeffmo>Bakkot: ^ do you know?
20:24:49  * Fishrock123joined
20:42:48  <ljharb>jeffmo: what restriction?
20:43:00  <ljharb>i'd assume you can have `static foo = 3; #foo = 4`?
20:43:08  <ljharb>also `foo = 5`
20:48:27  <jeffmo>ljharb: you cannot
20:49:35  <jeffmo>At least for purposes of room to make decisions around the design of the shorthand syntax's semantics in the future
20:53:51  <ljharb>hm
20:53:55  <ljharb>that seems very weird
20:54:04  <ljharb>can i have `foo = 3; #foo = 4`?
21:05:21  <TabAtkins>jmdyck: `oldids` is precisely the attribute name Bikeshed uses for this purpose. (Multiple IDs are comma-separated.)
21:08:49  <littledan>jeffmo: I'm not sure how you'd resolve whether you're talking about the static name or the instance name
21:08:57  <littledan>jeffmo: Or would you just use one name for both of them together in that case?
21:09:14  <littledan>when you see x.#y, which private name do you use for #y if both declarations exist?
21:13:10  <jmdyck>TabAtkins: I woulda thought space-separated.
21:14:12  <jeffmo>littledan: without shorthand it's pretty clear which you're talking about (the receiver is explicit)
21:14:24  <TabAtkins>You can put spaces in an ID. (I think it's invalid, but it happens.)
21:14:42  <littledan>jeffmo: I don't understand; if you're looking at `x.#y`, how do you know whether `x` is an instance or the constructor?
21:14:49  <jeffmo>With an explicit receiver it's just as clear as normal dot-syntax
21:14:56  <TabAtkins>I also have learned over time to just jump straight to comma-separation early, so I don't regret it later when I want to expand the value space.
21:15:01  <jeffmo>x is an instance of something
21:15:03  <littledan>I mean, how is this clear to the implementation?
21:15:04  <littledan>I get how programmers can have the intuition
21:15:06  <jeffmo>Either an instance of a class
21:15:17  <jeffmo>Or an instance of a class object
21:15:24  <jmdyck>TabAtkins: assuming you want to expand by adding space, not by adding comma.
21:16:44  <jeffmo>class C { #p = 42; static #p = 43; m() { C.#p; this.p; } }
21:17:15  <littledan>jeffmo: `x.#y` means, get the underlying Private Name for #y from the local lexical scope, then try to read that private field from x. Would we somehow have two names for #y, or would the static and instance fields share the name?
21:17:37  <littledan>I can picture how the semantics would work for the second one, but not the first
21:17:45  <TabAtkins>jmdyck: Please, I'm a CSSer, commas are *clearly* a higher-level separator than spaces.
21:17:52  <TabAtkins>(And slashes are between the two.)
21:18:19  <jmdyck>heh
21:18:28  <jeffmo>littledan: In the map in the local scope, you first look up the receiver. The receiver is either an instance of C or it is the object C itself
21:20:07  <jeffmo>#y is specific to the receiver
21:20:12  <littledan>eesh, the current spec text is really careful to not be based on either of those two concepts
21:20:23  <jeffmo>which two concepts?
21:20:43  <littledan>checking if the receiver is the constructor, or checking if it is "an instance of" a class
21:20:54  <jeffmo>you don't really have to
21:21:06  <jeffmo>any more than you have to check if a receiver is inst0 vst inst1
21:21:11  <littledan>the lookup is simpler than that. it just looks up the private name in the scope, and tries to read that from the instance
21:21:26  <littledan>well, I just don't understand what semantics you're proposing
21:21:29  <jeffmo>littledan: why not do the same, except have slots for a class object?
21:21:43  <littledan>we could use the same private name for both the constructor and the instance, sure
21:21:56  <littledan>using different private names sounds really hard
21:22:07  <jeffmo>I'm confused by your confusion :p
21:22:30  <littledan>I was asking, 'jeffmo: `x.#y` means, get the underlying Private Name for #y from the local lexical scope, then try to read that private field from x. Would we somehow have two names for #y, or would the static and instance fields share the name?'
21:22:33  <littledan>it sounds like, obviously, we'd have just one name
21:22:45  <littledan>the name isn't #y, it's what you get when you look up by the key #y in the local lexical scope
21:23:09  <littledan>currently, we only have one initializer for each private name, but nothing depends on that, and decorators can break it
21:23:29  <jeffmo>I think I see now -- maybe I need to re-read the spec, I might have glossed over some stuff assuming I knew more than I did
21:24:29  <littledan>I think we could make this work, it would just take a tiny bit extra logic to coalesce the two declarations, and say that we allow this specific case while prohibiting other private redeclarations
21:25:01  <littledan>but the mental model is weird. If the constructor slips into a place where you expect an instance, you won't get the TypeError you might expect
21:25:04  <jeffmo>at minimum I think it makes sense to restrict this until we decide if we want Waldemar's Java semantics for the shorthand
21:25:17  <littledan>I don't see the connection
21:25:27  <jeffmo>with Waldemar's Java semantics?
21:25:33  <littledan>oh, I see, it would ruin the alternative shorthand semantics
21:25:42  <littledan>since the name would correspond to either one, and be ambiguous
21:25:45  <jeffmo>right
21:26:04  <jeffmo>if we go with that, it's a moot point. If not, we could always unlock further in the future (if we decide it's tenable)
21:26:41  <littledan>but there's an easy, unprincipled fix there--decide whether to go with the class or instance version based on whether you're in a static method/initializer or not
21:26:59  <littledan>rather than by what the name is
21:29:16  <jeffmo>littledan: right, but that's a semantic choice that Waldemar opposes
21:29:22  <jeffmo>personally I'm in favor of that
21:29:32  <jeffmo>it keeps the shorthand as strictly sugar for `this.#foo`
21:29:47  <littledan>oh, right, that defeats the whole purpose
21:54:24  * bradleymeckquit (Quit: bradleymeck)
21:55:55  <ljharb>sorry i'm confused
21:56:37  <ljharb>i get why `static #foo = 3;` and `#foo = 4` might not be able to coexist right now - is that all we're talking about?
22:03:05  * Fishrock123quit (Remote host closed the connection)
22:04:45  * Fishrock123joined
22:12:40  <Domenic>Woah did IRCCloud start treating backticks as code? `test`
22:12:43  <Domenic>Neato!
22:12:52  <Domenic>More markdown? *test* _test_ **test**
22:40:10  <cloudshu>i just see those as backticks and asterisks still
22:47:27  <Domenic>Only backticks seemed to do anything
22:54:08  <ljharb>aha, i had to refresh but i see it now. spiffy!