00:25:33  * Draggorquit (Read error: Connection reset by peer)
01:01:36  * joyeejoined
01:03:16  * isHavvyGhostingchanged nick to isHavvy
01:32:56  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
02:05:24  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
03:31:36  * srl295quit (Quit: Connection closed for inactivity)
04:00:07  * Draggorjoined
04:16:46  * jmdyckquit (Remote host closed the connection)
07:16:09  * seishunjoined
09:01:58  * jdalton_quit (Quit: Connection closed for inactivity)
10:25:24  * mylesborinsquit (Quit: farewell for now)
10:25:55  * mylesborinsjoined
11:08:19  * AtumTjoined
11:34:05  * Draggorquit (Read error: Connection reset by peer)
12:42:26  * jmdyckjoined
13:16:31  * howdoiquit (Quit: Connection closed for inactivity)
14:07:50  * bradleymeckjoined
14:08:58  * bradleymeckpart
14:09:17  * bradleymeck_quit
14:09:48  * bradleymeck_joined
14:09:51  * bradleymeck_quit (Client Quit)
14:12:12  * bradleymeckjoined
14:30:17  * Draggorjoined
16:11:11  <ljharb>mathiasbynens: isn't the "groups" property supposed to only be present on the match object when the regex has groups, to ensure back compat?
16:12:49  <ljharb>i'm asking because in node 10, `'groups' in /a/.exec('a')` returns true, and that seems like a bug
16:12:57  <ljharb>(and it's breaking one of my packages' tests)
16:15:36  <ljharb>i guess i see in https://tc39.github.io/ecma262/#sec-regexpbuiltinexec step 26 that it's supposed to always be present
16:29:08  * keith_mi_joined
16:39:40  <Bakkot>ljharb: it was changed to the current state after discussion in committee IIRC
16:40:05  <ljharb>lol yeah it's entirely possible i argued for it to be the way it is now
16:40:15  <ljharb>"i do not recall"
16:42:20  <Bakkot>seems to be in https://github.com/rwaldron/tc39-notes/blob/e6644efb75c105f93713301caabf0587230f8a6a/es8/2017-03/mar-21.md#10iib-regexp-named-groups-for-stage-3
16:42:36  <Bakkot>er, or the previous meeting
16:44:06  * jdalton_joined
16:44:19  <ljharb>aha, that's one of the two meetings i wasn't at
16:50:29  * mylesborinsquit (Ping timeout: 260 seconds)
16:50:57  * vikash-afkquit (Ping timeout: 240 seconds)
16:51:28  * mylesborinsjoined
16:54:52  * vikash-afkjoined
17:10:30  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:11:23  * keith_mi_joined
18:07:46  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:08:16  * keith_mi_joined
19:10:06  * srl295joined
19:14:41  <caitp>what if you could use private names within object literals within a class scope, so that you could have factory methods which return objects with private state
19:17:11  <bradleymeck>caitp: why just class scope? https://gist.github.com/bmeck/baa8f21cb0b33d4c0db3aad05a38473a
19:18:13  <bradleymeck>caitp: importing private names gets a bit wonky though but is doable
19:23:49  <caitp>well, lets say "within a valid PNE"
19:24:21  <bradleymeck>"PNE"?
19:24:31  <caitp>P(rivate)N(ame)(E)nvironment
19:24:58  <bradleymeck>ah
19:25:20  <bradleymeck>caitp I really want that feature, removes a lot of weakmap pain
19:25:32  <caitp>wow i mixed up the acronym conventions half way thru describing the acronym
19:26:38  <bradleymeck>cross module is less common and can probably be punted, but in general would remove a fair bit of decorator usage for me as well
19:26:57  <caitp>the other thing is, I'm not sure if it should be "PrivateFieldSet only works if the field has been added via PrivateNameAdd" --- like, maybe you want to add a private flag to some object passed in through the API to indicate a state of processing it or something
19:28:08  <bradleymeck>caitp: not sure I understand that, can't you just add a state field or do some sort of check like in last example file of that gist?
19:28:10  <caitp>or is it PrivateFieldAdd, whatever
19:29:04  <caitp>step 4 of https://tc39.github.io/proposal-class-fields/#sec-privatefieldset
19:31:30  <bradleymeck>ah, yea, that is somewhat an issue if you want to add private fields after construction
19:44:41  <ljharb>i don't think you're supposed to be able to add private fields after construction in this proposal
19:46:02  * seishunquit (Ping timeout: 268 seconds)
19:47:50  <caitp>you aren't. but I'm not sure that's a good thing :p
19:48:02  <caitp>but also not sure it's not
19:56:01  <ljharb>i think you have WeakMaps if you want to add private data to things you don't own
19:56:06  <ljharb>and things you own, you'd create with the private field
19:56:43  * jwaldenjoined
19:57:07  <caitp>i mean, yes, but don't you think private state is a weird use for weak maps
19:57:15  <caitp>seems like the wrong abstraction
19:58:22  <ljharb>no? that's the main value of weak maps imo - private side channel data
19:59:19  <caitp>i see it as an association without retaining the associated key --- that association could hold private data, sure --- but not necessarily
19:59:50  <caitp>in my mental model, associating private state isn't the point of it
20:03:52  <ljharb>ok, but via closure, it'd be private too
20:04:07  <ljharb>and i think the mental model of "private state" is something that is only known by the owner of the code
20:04:13  <ljharb>meaning, you can't imbue it on something you don't own
20:04:52  <Bakkot>ljharb: you are explicitly able to add private fields after construction using the return-override trick, but that's a pattern to encourage
20:05:26  <Bakkot>anyway, strongly agreed that weakmaps are the correct abstraction for keeping private information about objects you don't own
20:05:28  <ljharb>Bakkot: wait, that doesn't make sense. you mean a return-overridden object can have `.#foo = 3` on it?
20:05:43  <ljharb>if i return-override then it shouldn't have any of the private state of `this` or of its superclasses
20:05:58  <caitp>performance wise, it's possible (likely even) that weak maps will work better for arbitrary objects instead of adding new fields and causing map migrations for things that don't belong to you --- but it's still a collection of objects associated with some other objects without retaining the "some other objects", when what you really want is a way to give some other arbitrary object a boolean field indicating that you've
20:05:58  <caitp> already looked at it.
20:06:23  <caitp>so it's kind of a weird abstraction for doing that
20:06:29  <ljharb>caitp: right but you should never mutate - "give a field to" - something you don't own, so i think the separate side channel is the better abstraction.
20:07:32  <bradleymeck>i'm not sure i really see the difference in mutation by adding a private field or by adding a weakmapping
20:07:38  <Bakkot>ljharb: I mean that you can add things to an object which already exists using return-override:
20:07:40  <Bakkot>{ let o = {}; new class extends class { constructor(){ return o; } } { #x = 0; constructor() { super(); console.log(this === o && this.#x == 0); /* true */ } } }
20:08:00  <bradleymeck>you can't extract that a weakmap or private field exists on a reference without having the map or field available already
20:08:22  <caitp>conceptually, the map is a collection of associations, whereas the private field is a singular association
20:08:38  <caitp>it's a conceptual difference
20:08:50  <bradleymeck>not sure i agree on that point
20:08:55  <Bakkot>caitp: it might just be bias from how I've been in the habit of doing this, but I am really, really used to using side-tables to hold for information about objects I don't own
20:09:21  <bradleymeck>a private field is a way of including data/producing a binding not necessarily the bindings themselves
20:09:44  <ljharb>Bakkot: ah i see, you mean by extending it. ok, fair
20:09:52  <bradleymeck>just like i don't think of strings/symbols as properties
20:10:06  <Bakkot>caitp: part of that is just that I am strongly in the habit of treating objects I don't own as immutable, I guess
20:10:16  <ljharb>(as are most JS devs, i would hope)
20:10:26  <bradleymeck>ljharb: dreams
20:10:47  <caitp>if they don't know you've mutated them, and it doesn't affect their stuff... did you _really_ mutate them?
20:10:54  <caitp>I mean from the engine's PoV yes, but...
20:11:40  <ljharb>lol fair, but at that point it's semantically a side channel
20:12:01  <bradleymeck>just like a weakmap does
20:12:03  <Bakkot>arguably no, but thinking of doing that would require me thinking of them as mutable, even though the mutation isn't observable to anyone else
20:12:10  <ljharb>^
20:13:14  <bradleymeck>Bakkot, not sure I understand that last statement
20:13:40  <bradleymeck>if there are any side channels tied to the lifetime of a reference, how is it not seemingly mutation
20:14:00  <bradleymeck>for that point even properties are similar just not thought of as "side"
20:14:01  <Bakkot>bradleymeck: I mean that if I am treating `o` as immutable, I'm not going to think "Oh, I can do `o.#x = 0` to mark it". Didn't mean to reply to the side-channel comment
20:14:09  <caitp>we don't have `const& parameter` in JS, so we're forced to imagine it
20:14:39  <caitp>which is fair I guess
20:14:44  <bradleymeck>Bakkot: we have a difference in mental model i think
20:16:01  <bradleymeck>private fields are not really something i think of as being exactly like properties, i see them more like a special binding type
20:16:58  <bradleymeck>they don't do delegation, they don't have reified keys, etc.
20:18:09  <Bakkot>I definitely do think of them as being like properties except private.
20:19:23  <bradleymeck>they act different enough that i can't think of them like properties without breaking my view of how properties work in JS. even with decorators they aren't reified to act like a key of a property
20:20:13  <bradleymeck>the PrivateName#get/set is closer to a WeakMap API thank a key for a property
20:20:21  <bradleymeck>than*
20:20:28  <ljharb>they're definitely like properties
20:20:34  <ljharb>even tho you'd model them with weakmaps
20:20:46  <bradleymeck>ljharb: I do not think so
20:20:58  <bradleymeck>they have a syntax very similar to properties, yes
20:21:03  <Bakkot>well, we do have a difference in mental model then, yes!
20:21:12  <Bakkot>Neither is objectivel correct
20:21:16  <bradleymeck>yup
20:22:09  <Bakkot>for me, the important things are "it's a value stored on the object, and (to a much lesser degree of importance) if I invoke a function via it then it passes the object as the function's receiver"
20:22:18  <Bakkot>which is where my "it's like a property" mental model comes from
20:23:03  <bradleymeck>i view that as the dispatch mechanism of `.#` not on the private field itself
20:24:05  <bradleymeck>it forms the reference from the private field, the function call is separated from that in my mind
20:24:18  <ljharb>what about `a.b()`?
20:24:25  <ljharb>isn't that the same?
20:24:49  <bradleymeck>@ljharb `a.b` forms a reference sure, but `.b` doesn't act like `.#b`
20:25:03  <ljharb>in what way is it different?
20:25:33  <ljharb>it doesn't walk the prototype chain, sure, but it's still accessing something that belongs to `a`, by name
20:25:34  <bradleymeck>lack of delegation, lack of dynamic property in reference formation, lack of #b being a value that can be passed around
20:25:38  <Bakkot>I definitely do not think about `a.b()` at a level of precision at whichthe notion of a reference would enter into things, in day to day life
20:25:45  <ljharb>bradleymeck: `b` isn't a value that can be passed around either
20:25:56  <bradleymeck>ljharb: it is a shorthand for `['b']`
20:26:04  <ljharb>`.b` is syntax that *ends up* being `['b']`, but that's not the same thing
20:26:12  <bradleymeck>how do they differ
20:26:19  <ljharb>different restrictions
20:26:31  <ljharb>identifier vs not
20:26:38  <bradleymeck>you mean syntax?
20:26:42  <ljharb>yes
20:26:46  <bradleymeck>my mental problem is with semantics not syntax
20:26:55  <ljharb>yes but "being syntax" has its own semantics
20:27:06  <bradleymeck>i'm not sure i follow that bit
20:27:07  <caitp>the only mention of the "private reference flag" in the proposal is the part that forbids "delete" on private fields
20:27:28  <Domenic>bterlson: does Ecmarkup still need manual bibliography updates? I am getting lots of xref errors for async generator stuff
20:27:53  <ljharb>bradleymeck: it means that the fact that ".b" and "['b']" have the same semantics does *not* mean that dot access has the semantics of "you can do bracket access with it"
20:28:20  <caitp>well, going through IsPrivateReference it also dictates that you use PrivateValueGet and PrivateValueSet in GetValue and PutValue, but I mean, those aren't super different
20:28:32  <bradleymeck>ljharb: define "it" in that last bit
20:29:02  <bradleymeck>when is there a `.` access that doesn't work with `[]` access once converted to a string
20:29:09  <caitp>"throw if base is not an object", "don't walk prototype", "throw if the field doesn't exist"
20:29:41  <caitp>but those are the key differences?
20:30:33  <bradleymeck>caitp: those are differences between private reference and property references yes
20:31:16  <caitp>I know that, I was just wondering if those were the semantic differences you were referring to
20:31:30  <caitp>because apart from that, what else is there
20:31:32  <ljharb>bradleymeck: that "it" being "the part after the dot"
20:31:59  <ljharb>bradleymeck: the fact that currently there's no "dot access that doesn't work with bracket access once converted to a string", does not mean that's part of the definition of "property"
20:32:09  <Bakkot>caitp: is "throw if base is not an object" actually distinct from "throw if the field doesn't exist"? accessing public properties has `requireObjectCoercible`, so the difference is just in what happens when accessing properties of non-null/undefined primitives. but those always lack the private fields and so the throwy-ness there is already covered
20:32:16  <bradleymeck>caitp: the reference has a non-reifiable value as part of it is a big mental shift for me
20:32:21  <ljharb>bradleymeck: it might be part of the definition of "public property", but private properties are different and that's ok
20:32:53  <Bakkot>bradleymeck: interesting; I definitely don't consider the reifiability of public properties to be a bit part of my mental model of them
20:32:56  <bradleymeck>ljharb: correct, but things like Symbol access also don't work with `.` but are following the same rules as other references
20:33:04  <Bakkot>possibly because I write a lot of java/C++/etc
20:33:23  <bradleymeck>Bakkot: it means I can't share that part of the reference
20:33:28  <caitp>Bakkot: well in the current proposal, the only things that can ever have private fields are objects declared using class syntax and created with `new <class>`, so in that sense they aren't different
20:34:39  <ljharb>JS has bindings but not reified references
20:34:44  <Bakkot>bradleymeck: yeah. that also is not a big part of my mental model of properties.
20:34:46  <ljharb>so there's no "reference" to share
20:34:59  <bradleymeck>ljharb: part of reference != reference
20:35:29  <bradleymeck>kinda like directory names aren't paths unless you join them into a different thing
20:35:29  <caitp>I'm not sure what you mean by "reifiable" --- how are you using "reify" here? like, it's not a concrete value you can reference in JS the way symbols are?
20:35:36  <ljharb>correct
20:35:41  <bradleymeck>^
20:37:00  <bradleymeck>caitp: by being only lexical instead of being a value to runtime i say that private fields have no reified form, they only have values as a result of their references
20:37:34  <bradleymeck>but all this talk is about mental models not matching, nothing is correct/incorrect really
20:39:01  <bradleymeck>classes 1.1 had a very similar model to how i think of private fields but just renamed the feature to instance variables instead
20:43:14  <Bakkot>er. classes 1.1 had exactly the same model of private fields as the current state of things, no? except that they didn't brand-check methods.
20:43:32  <ljharb>it did.
20:44:49  <bradleymeck>Bakkot: yep, but their framing as bindings made much more sense to me than trying to treat private fields as the same thing as existing stuff
20:44:57  <caitp>bradleymeck: I think that's a reasonable perspective for a JS developer --- engine implementors will probably see it differently. being both, that's why I was a bit confused
20:45:21  <caitp>reified can have some different meanings, like "lazy" accessors that get turned into data properties in v8 and jsc
20:46:05  <bradleymeck>caitp: yea, terminology is very loose in this area
20:46:13  <bradleymeck>sorry for the confusion
20:46:26  <caitp>all good
20:59:07  <caitp>so here's an interesting thing --- if a super constructor returns `Object.freeze(this);`, PrivateFieldAdd doesn't seem to care about if the object is extensible or not. should it?
20:59:29  <caitp>and, does Object.freeze make private fields read only?
20:59:37  <Bakkot>Nope to both per https://github.com/tc39/proposal-private-fields/issues/69
20:59:37  <ljharb>it does not
20:59:51  <ljharb>freeze is only "public property freeze", and doesn't make things immutable
21:00:05  <ljharb>just like `Object.freeze(aMapInstance)` still leaves that map mutable
21:00:29  <caitp>it makes them non-extensible, and makes properties read only
21:00:50  <caitp>configurable doesn't really matter in the case of privates since you can't configure them anyway currently
21:01:12  <caitp>so, extensible doesn't matter, and freeze ignores private fields, got it
21:01:14  * bradleymeckstill chuckles at enumerable vs non-enumerable symbols
22:11:10  <devsnek>does private property access get affected at all by redefining the function rebinding it etc
22:14:16  <Bakkot>devsnek: I don't know what that means
22:14:35  <devsnek>like if you have some member function that accesses a private symbol
22:14:53  <devsnek>and you call it with a different `this` or something
22:15:29  <Bakkot>if you try to access a private property on an object which lacks it, that immediately throws a typeerror
22:16:08  <Bakkot>this is true if you `.call` a function which has `this.#x`, but also if you just have something like `foo(a){ a.#x }` and pass in a non-instance
22:16:30  <devsnek>oh i never knew you could perform .# accessor on not-this
22:17:08  <Bakkot>yup: https://github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md#why-does-this-proposal-allow-accessing-private-fields-of-other-instances-of-the-same-class-dont-other-languages-normally-forbid-that
22:54:43  * not-an-aardvarkjoined
23:48:58  * ephemera_quit (Ping timeout: 264 seconds)