00:03:21  * akirosequit (Ping timeout: 258 seconds)
00:03:32  * akirosejoined
00:04:58  * AtumT_quit (Quit: AtumT_)
00:06:08  * keith_mi_joined
00:46:02  * NaNjoined
00:46:19  * NaNchanged nick to Guest50841
00:47:20  * Guest50841part
00:49:04  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:25:30  * cloudshuquit (Quit: Connection closed for inactivity)
01:41:01  * cloudshujoined
01:50:43  * keith_mi_joined
01:52:30  * keith_mi_quit (Client Quit)
01:54:46  * keith_mi_joined
02:07:03  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
02:08:08  * gibson042quit (Ping timeout: 268 seconds)
02:10:27  * aki_joined
02:11:22  * akirosequit (Ping timeout: 250 seconds)
02:11:22  * aki_changed nick to akirose
02:16:11  * keith_mi_joined
02:18:20  * keith_mi_quit (Read error: Connection reset by peer)
02:18:45  * keith_mi_joined
02:20:28  * keith_m__joined
02:23:11  * keith_mi_quit (Ping timeout: 244 seconds)
02:28:08  * keith_mi_joined
02:29:51  * keith_m__quit (Remote host closed the connection)
02:32:00  * keith_m__joined
02:32:51  * keith_mi_quit (Remote host closed the connection)
02:33:25  * keith_mi_joined
02:36:30  * keith_m__quit (Ping timeout: 250 seconds)
03:05:43  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
04:17:07  * aki_joined
04:18:16  * akirosequit (Ping timeout: 258 seconds)
04:18:16  * aki_changed nick to akirose
04:22:06  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
05:05:30  * cloudshuquit (Quit: Connection closed for inactivity)
05:05:56  * jmdyckquit (Remote host closed the connection)
05:12:04  * devsnekquit (Ping timeout: 264 seconds)
05:14:50  * devsnekjoined
06:23:56  * aki_joined
06:25:06  * akirosequit (Ping timeout: 272 seconds)
06:25:06  * aki_changed nick to akirose
08:05:07  * nomadtechiequit (Read error: Connection reset by peer)
08:05:07  * rkirslingquit (Read error: Connection reset by peer)
08:05:08  * samthquit (Read error: Connection reset by peer)
08:05:22  * samthjoined
08:05:23  * rkirslingjoined
08:05:24  * nomadtechiejoined
08:31:27  * akirosequit (Ping timeout: 240 seconds)
08:32:10  * akirosejoined
09:12:56  * akirosequit (Quit: 👋🏻)
09:16:16  * akirosejoined
10:09:45  * dpkquit (Ping timeout: 260 seconds)
10:13:23  * dpkjoined
10:18:32  * mgoljoined
11:23:23  * akirosequit (Ping timeout: 258 seconds)
11:26:35  * akirosejoined
12:31:06  * m_goljoined
12:33:12  * mgolquit (Ping timeout: 250 seconds)
12:56:11  * mgoljoined
12:57:08  * m_golquit (Ping timeout: 245 seconds)
13:18:03  * keith_mi_joined
13:25:02  * jmdyckjoined
13:33:05  * akirosequit (Ping timeout: 246 seconds)
13:35:08  * akirosejoined
14:31:06  * gibson042joined
14:52:52  * jorydotcomjoined
15:04:26  * keith_mi_quit (Ping timeout: 250 seconds)
15:05:57  * keith_mi_joined
15:35:41  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:41:19  * aki_joined
15:42:24  * akirosequit (Ping timeout: 272 seconds)
15:42:25  * aki_changed nick to akirose
15:48:13  * keith_mi_joined
15:49:25  * cloudshujoined
16:04:18  <devsnek>littledan: i think maybe we're talking past each other?
16:04:43  <devsnek>my point was that the private fields aren't tied to the prototype but rather the instance
16:04:47  <littledan>devsnek: Could be; sorry I didn't review your comments here yet
16:04:48  <littledan>yes, that's true
16:04:53  <littledan>that's a design goal, basically
16:05:05  <littledan>internal slots and WeakMaps are like that too
16:05:12  <devsnek>so like if you have `class X { #y; constructor() { return {} } }`
16:05:32  <devsnek>you've "discarded" the instance of X with `#y` on it
16:05:34  <littledan>none of your examples use `class.initialize`, so I don't know what sort of point you're making about that proposal
16:05:35  <littledan>yes
16:05:58  <devsnek>regardless of if that return value comes from `Object.create(new.target.prototype)`
16:06:03  <littledan>right
16:06:05  <devsnek>you're opting out of using those private fields
16:06:10  <littledan>yes
16:06:29  <devsnek>so to me, the entire issue seems like its looking for the wrong solution
16:06:54  <littledan>What do these facts about the semantics of the fields proposal have to do with it being a bad idea to make a mechanism to not opt out of it?
16:07:02  <littledan>to opt back into it
16:07:24  <littledan>I mean, how would you allow the original superclass constructor to reliably be called?
16:08:21  <devsnek>explicitly call it?
16:09:54  <littledan>that's exactly the pattern I'm suggesting in the class.initialize readme
16:09:55  <bradleymeck>that won't install the private fields though
16:09:59  <littledan>right
16:10:14  <devsnek>all you lose is the fields of the current class
16:10:16  <devsnek>not the super
16:10:17  <bradleymeck>you need to add some way to strap those fields onto an object that != what super() returns
16:10:28  <littledan>yes, that's true
16:10:37  <littledan>the bug Domenic filed was all about getting the fields in the subclass
16:10:40  <littledan>https://github.com/littledan/proposal-class-initialize
16:10:49  <littledan>this explains clearly that it's all about getting the fields in the subclass
16:11:01  <littledan>you could argue that built-in classes add all the fields in the base class, though
16:11:20  <devsnek>yeah and my whole point here is that the fields of the subclass are gone
16:11:25  <littledan>it's ambiguous, though, since web specs aren't really clear about their use of internal slots (which is being discusse das an area for improvement in WebIDL)
16:11:27  <devsnek>like you've decided to return something else
16:11:39  <littledan>so, yes ,that's something you can accomplish with the class fields proposal without changes
16:12:05  <littledan>I think you understand the semantics well, and the disconnect is, I don't know where you go from the "is" to "should"
16:12:22  <littledan>yes, you can write code that does that stuff. Why does that mean that we shouldn't add this feature to do other stuff?
16:12:35  <devsnek>🤷 it just feels like the wrong semantics
16:12:41  <littledan>what feels wrong about it?
16:13:11  <devsnek>there's a difference between an instance of X and the result of Construct(X)
16:13:46  <devsnek>a difference that is very explicit outside of spec land because of return overrides
16:15:16  <devsnek>its like those proposals to do `constructor(.x)` to make it automatically assign to `this.x`, its a very common pattern and there's definitely logic in that syntax and behaviour but it connects two ideas which still have a separation and therefore feels weird
16:16:55  <devsnek>i think the word i used in the issue is "contrived"
16:16:56  <littledan>I don't quite understand what you're saying. Do you mean, fields and private methods are logically something that you should only get from "really" returning from super, and anything that violates that is unexpected?
16:17:23  <littledan>this is a bit different from `constructor(.x)` in that that proposal is a shortcut, whereas this is a power tool
16:17:48  <littledan>so I expect the situations where they are used will be different
16:19:29  <devsnek>if you're not using the instance of X, don't bother having those private fields
16:19:37  <devsnek>use something else, maybe private symbols
16:21:04  * gibson042quit (Ping timeout: 268 seconds)
16:21:08  <littledan>private symbols don't exist, and I'm not confident that they will exist in the future
16:21:32  <littledan>do you share Domenic's concern about what the issue means for the private fields and methods proposals overall?
16:22:22  <devsnek>that its not well suited to describe the relationships of dom elements?
16:23:23  <littledan>that seems to be Domenic's claim, and my proposal to rectify things is class.initialize (+ decorators to allow friends to happen)
16:26:09  <cloudshu>devsnek: what feels like the wrong semantics? the existing return override behavior for fields, or providing it via class.initialize as proposed?
16:26:27  <devsnek>the latter
16:26:37  <devsnek>i think the current behaviour is 👍
16:27:47  <cloudshu>devsnek: then i'm similarly confused... the existing behavior itself doesn't feel wrong, but giving programmatic access to it feels wrong?
16:29:40  <devsnek>cloudshu: it feels like everything together makes weird semantics that's like js trying to get around itself
16:30:01  <devsnek>dropping an instance to make another identical-ish one feels like poor design
16:32:24  <cloudshu>devsnek: i see. my point of view is a bit different. in that class behavior in JS differ form object behavior in JS, i see this as a step towards having programmatic reflection of something like a "metaclass protocol"
16:33:00  <devsnek>i don't disagree with having that in general
16:36:26  <littledan>note that, in subclasses (the case where I think this feature is most useful), there's no instance being dropped in favor of another one; it's just never created
16:36:55  * gibson042joined
16:36:56  <littledan>but, for base classes, dropping one thing in favor of another has been the semantics of `new` since the two tablets were passed down to Brendan, or however it happened
16:37:19  <littledan>so, none of this really is a property of `class.initialize`
16:37:22  <devsnek>i assume you mean you mean if you don't call super
16:37:33  <littledan>exactly
16:37:40  <devsnek>if you're opting out of all the class things
16:37:44  <devsnek>why even bother using classes
16:37:47  <littledan>`class.initialize` is exactly to cover the cases where you don't call super
16:38:06  <littledan>you're not opting out of all of them, just this one little part
16:38:16  <littledan>you use classes for all of the other reasons
16:38:25  <littledan>I mean, this is justified for the same reason it makes sense to have Reflect.construct
16:38:25  * AtumTjoined
16:39:26  <devsnek>well if everyone disagrees with me i'm probably the crazy one
16:39:33  <littledan>well, I just don't understand this design perspective
16:39:48  <littledan>I agree that this proposal isn't the highest priority one in the universe
16:40:00  <littledan>I explain mitigations for its lack in the readme
16:40:32  <littledan>but, if we consider the thing that Domenic posted about as a design goal, then this is the best solution I can think of, and it should be prioritized wherever we prioritize his concern.
16:40:38  <cloudshu>is the point that "one shouldn't be able to opt out of class behavior piecemeal" about invariants?
16:44:31  <littledan>I don't see what invariant this would relate to
16:45:53  <cloudshu>the only one i can think of is the obvious one: the instance called super() if and only if the instance has the class's fields installed
16:46:04  <cloudshu>but that doesn't seem that useful an invariant
16:59:03  <cloudshu>well, i take that back, could be useful for VMs
17:06:47  <littledan>it could be something that vms speculate on, sure
17:06:58  <littledan>I am not sure what guarantees vms could use
17:07:43  <cloudshu>vms speculating on that is still fine in that class.initialize is an easy-to-detect deopt
17:14:34  <littledan>yeah
17:14:42  <littledan>did you get my email about the TypeErorr thing?
17:15:01  <littledan>oh oops I didn't send it yet
17:15:26  <cloudshu>ah
17:15:53  <bradleymeck>how do people feel about another global table like the global symbol table for compositeKey, rather than me making a synthetic internal slot to that is only ever used by compositeKey (some functions have internal slots already so idk)
17:35:30  * jwaldenjoined
17:43:46  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:48:50  * aki_joined
17:49:06  * akirosequit (Ping timeout: 250 seconds)
17:49:09  * aki_changed nick to akirose
18:02:12  * kverrierjoined
18:02:13  * kverrierquit (Client Quit)
18:39:12  <devsnek>jridgewell's private symbol proposal is really nice
18:40:33  <cloudshu>i disagree, it seems to carve out a 3rd semantics space different from both weakmap semantics and property semantics
18:40:46  <Domenic>+1
18:41:28  <devsnek>i like both but justin's feels more javascripty
18:45:00  <devsnek>cloudshu: what do you mean its different from property semantics
18:45:52  <cloudshu>devsnek: i mean it doesn't behave like properties in fairly significant ways
18:46:08  <devsnek>it behaves exactly like properties except for OwnPropertyKeys
18:46:54  <cloudshu>devsnek: it behaves like private fields except no error on not found and prototype chain lookups
18:47:09  <devsnek>that's just regular properties
18:48:05  <cloudshu>devsnek: well, what do the bits on the property descriptors mean now?
18:48:14  * mgoljoined
18:48:29  <cloudshu>devsnek: i think it's a far stretch from "just regular properties"
18:48:29  <devsnek>huh
18:49:10  <cloudshu>devsnek: what does enumerability mean for these properties?
18:49:20  <devsnek>the entire proposal is "private symbols as non-exposed symbols with [[Private]] and not shown in OwnPropertyKeys"
18:50:06  <devsnek>i guess you're right that the descriptors for them would be not used the same way, but since you can't see those descriptors either i don't think its a problem
18:50:45  <cloudshu>devsnek: in their behavior, i don't think you can say "they're just like properties" in that they behave very differently due to their encapsulated nature
18:50:53  <devsnek>you could just say an invariat of private name properties is that their descriptors are always [[writable]] true and [[enumerable]] false
18:51:13  <cloudshu>devsnek: and in that light, it is a new set of semantics for a property-like feature from both regular properties and private fields
18:52:14  <devsnek>i guess we just don't see it the same way :P
18:52:26  <cloudshu>devsnek: and it is strictly less desirable from a simplification for me POV because this is neither regular properties, which are well understood, nor private fields, which are weakmap semantics (which already exist)
18:52:36  <cloudshu>err, from a simplification POV for me*
18:53:15  <cloudshu>devsnek: that's my disagreement with the "this is simpler to understand" narrative
18:53:33  <devsnek>from the examples in https://github.com/jridgewell/proposal-private-symbols it seems pretty simple to use and understand
18:53:34  <cloudshu>i have a more fundamental disagreement with doing proto lookups
18:54:13  <devsnek>that is the main reason that reified private symbols got stuck right?
18:54:14  <cloudshu>devsnek: for straightforward use, both private fields and private symbols are easy to understand
18:54:29  <cloudshu>part of the impetus for symbols was to simplify also the edge cases
18:54:39  <cloudshu>whereas this new proposal introduces different edge cases instead, imo
18:54:58  <bradleymeck>devsnek: it also got stuck due to some usability issues with lacking the check for if the target has the fields
18:55:27  <devsnek>i'd definitely take private symbols over both
18:55:32  <cloudshu>devsnek: and we might very well disagree on the understandability of those different edge cases. i don't think the private fields edge cases are so bad, for instance
18:55:39  <bradleymeck>so if you were to setsPrivateField.call({}) it would install private fields on {} which is undesirable for preventing problems
18:55:44  <devsnek>but i think all three are good in their own ways
18:56:33  <bradleymeck>private fields aren't private in the same way as private symbols due to the checks for the fields
18:56:43  <devsnek>if private symbols were a thing why wouldn't `hasOwnProperty` work
18:56:48  <devsnek>or `in`
18:57:35  <bradleymeck>because you don't want them to be detectable, and `in` already has a meaning, overloading it won't do checks in a way that allows us to ensure that a value already has the private field
18:58:27  <devsnek>maybe i'm understanding what private symbols would be
18:58:33  <devsnek>i'm currently thinking of them as what v8 currently has
18:58:36  <bradleymeck>the way to move this kind of stuff forward I likely to stop trying to make them act like regular props
18:58:45  <devsnek>with %CreatePrivateSymbol
18:59:08  <bradleymeck>yup, there have been objections to that approach due to leakage concerns in the past
18:59:30  <devsnek>if they act like that all the existing semantics would work pretty well
19:00:18  <bradleymeck>the existing semantics are exactly what leak
19:00:34  <devsnek>how do they leak, you can't tell if a private symbol even exists unless you have a reference to it
19:01:46  <bradleymeck>p = new PrivateSymbol(); function danger(a) { if (a[p]) { /*do the thing*/ } }; function update(a) {a[p]++;};
19:02:03  <bradleymeck>weakmaps have a similar problem and private fields had to make changes to avoid the leakage
19:02:15  <devsnek>i don't understand where leakage happened in your example
19:02:25  <bradleymeck>if you do assignments when things don't exist you mark them as existing
19:02:42  <devsnek>don't create them if they don't exist
19:03:04  <bradleymeck>and that means you can't do brand checks safely using simple assignments, you start having to fall back to weakmaps to have it be safe, and doing so requires lots of .has checks
19:03:24  <bradleymeck>devsnek: exactly, that syntax usage of just adding them even if they don't exist is the problem
19:03:43  <devsnek>in chrome they did the brand check with `if (hasOwnProperty(obj, private)) {}`
19:03:50  <bradleymeck>you need some explicit initialization instead of simple assignment
19:04:00  <devsnek>yeah you need to add them
19:04:08  <devsnek>they don't just magically exist
19:04:36  <bradleymeck>thats what we don't want as the default behavior leads to boilerplate and requires programmer vigilance to opt out of unsafe behavior instead of opting into unsafe behavior
19:05:11  <bradleymeck>devsnek: yup, but the problem is in if the default behavior is problematic, which if it doesn't include that check it can be
19:05:23  <devsnek>https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/streams/ReadableStream.js?l=685
19:05:56  <bradleymeck>I know how they use them, but we are trying to have the defaults remain encapsulated, which private symbols in v8 do not default to
19:06:09  <bradleymeck>they require quite a bit of care to use safely still with the field checks
19:06:54  <devsnek>i still am missing how encapsulation is broken
19:06:55  <bradleymeck>hence why adopting them isn't desirable to several people, if they didn't require such care to use properly it likely wouldn't be an issue
19:07:34  <bradleymeck>devsnek: they require an external check to safely use. on their own, they do not present a safely encapsulated set of operations
19:07:44  <devsnek>you mean brand checking
19:08:08  <devsnek>like `if (obj[x]) {}` doesn't throw if `x` doesn't exist
19:08:15  <devsnek>doesn't exist on obj*
19:08:15  <bradleymeck>in this example, yes, the initialization of the field is overloaded also as the assignment to the field
19:08:24  <bradleymeck>devsnek: it does for private fields
19:08:32  <bradleymeck>because of this kind of problem
19:09:08  <cloudshu>bradleymeck: agree, i now think the present disagreement is just very fundamental -- whether airtight per-instance privacy should be a first-class position that JS expresses, as a language. and that it is rather impossible to compose that with property semantics well, certainly at a metaobject protocol level. so those who believe it is not an important position, then all of this is needless complexity. and there're also many
19:09:08  <cloudshu>folks who very strongly believe (myself included) that JS should definitely express this position
19:09:38  <devsnek>like i get that brand checks are useful and important, i don't get why they're connected to private data
19:10:29  <devsnek>and i'm not saying the current stage 3 proposal is bad, i'm fine with the semantics and have used them a bunch
19:12:59  <bradleymeck>private data that can be forged onto objects passed in from userland is the problem, that means that userland can make objects look like they came from privileged code that only expected objects that it explicitly listed to have the initialized private fields it uses. class.initialize is an explicit initialization as is the constructor operations for classes.
19:13:37  <Bakkot>i actually have much more of a problem with _partially_ forging them than forging them all at once in the constructor, which are kinda distinct cases
19:13:51  <Bakkot>in related news, I think I want to bring Object.freezePrototype before the committee this meting
19:13:54  <Bakkot>should get that ready
19:14:34  <bradleymeck>cloudshu: so you aren't for per-instance privacy?
19:14:46  <cloudshu>bradleymeck: no, i'm very much for per-instance privacy
19:14:50  <bradleymeck>oh
19:14:53  <bradleymeck>i misunderstood
19:15:09  <cloudshu>bradleymeck: i'm very much for the status quo
19:15:11  <devsnek>bradleymeck: like `x = Object.create(objWithPrivateProp); x.wellKnownMethod = ...`?
19:15:13  <cloudshu>of the current proposals
19:15:31  <cloudshu>Bakkot: what does freezePrototype do?
19:16:19  <bradleymeck>stops .setPrototypeOf probably
19:16:27  <bradleymeck>since only seal/freeze can do that right now
19:16:43  <cloudshu>ah, so you get the prototype part without at least preventExtensions
19:16:44  <cloudshu>sgtm
19:17:36  <Bakkot>yeah, that
19:19:54  <devsnek>bradleymeck: if you expect to have the actual object you can `hasOwnProperty` instead of `in`
19:20:05  <devsnek>just like they do in chrome...
19:20:32  <bradleymeck>still leaves the default usage via assignment as problematic
19:20:57  <devsnek>you mean how you have to explicitly add the symbol to objects?
19:21:26  <bradleymeck>you have to perform the check prior to all assignments
19:21:49  <devsnek>right
19:22:04  <devsnek>well not every assignment
19:22:09  <devsnek>just when you get an object from the outside world
19:22:14  <bradleymeck>if even mark complains about not being able to feel safe about manually doing all those checks i think its a hard sell
19:22:37  <devsnek>i don't understand why it's part of the sell
19:23:06  <bradleymeck>devsnek: everytime you interact, if you pass an object to the outside it could still add your private symbol to something that came from inside your code
19:23:35  <devsnek>you can accidentally add properties to anything
19:23:36  <bradleymeck>devsnek: it isn't a selling point, it is a problem with not doing the check automatically
19:23:37  <Bakkot>(and not the other symbols, leaving you only partially an instane!)
19:24:03  <bradleymeck>Bakkot: delicious partial instantiation is doable in all sorts of cases ;p
19:24:27  <devsnek>partial state feels out of scope of private data imo
19:24:36  <Bakkot>doable but usually not acidentally!
19:25:46  <Bakkot>devsnek: I think it's in scope: the point of private data is encapsulation. the point of encapsulation is making it easy to reason about the behavior of your code and its interactions with the rest of the world. "this thing is only partially an instance" is generally not a case anyone is going to even remember as a possibility, much less reason about correctly
19:26:05  <bradleymeck>devsnek: it is all related to what ways a programmer can find to weasel out of expectations
19:26:35  <devsnek>you can make getData and setData functions to enforce your invariants about accidental property creation
19:26:37  <bradleymeck>some things aren't problematic, others are depending on how likely it could be done accidentally and how much boilerplate needs to be performed to avoid it
19:26:41  <devsnek>you'll probably need them for regular properties too
19:26:57  <devsnek>since you can accidentally create those as well
19:27:21  <Bakkot>if you're always going to need them to reason about your code, they should just be given to you by the language
19:27:30  <devsnek>i don't think you do always need them
19:27:36  <devsnek>that's my point
19:27:37  <Bakkot>s/always/typically/
19:28:00  <bradleymeck>its pretty high near always if your fn is reachable via jargon like Function.prototype.call
19:28:03  <Bakkot>if someone is not thinking about the case, is it more likely that they do or do not need them? I think it is far, far more likely that they do need them
19:28:33  <devsnek>i feel like the need of branding is over-represented
19:29:14  <devsnek>the only times i've ever used strict branding like this (and the only examples people give me) are implementing polyfills of builtins
19:29:57  <Bakkot>devsnek: the only case it's not particularly useful is when you're developing code which is only for yourself.
19:30:52  <devsnek>i don't yet believe that the average code needs strict brand checks
19:31:15  <devsnek>and even engine builtins don't need them (in node we barely do checks, at most instanceof)
19:31:59  <bradleymeck>devsnek: in node we have tons of problems due to not locking down core
19:32:18  <Bakkot>web platform apis are all very heavily brand checked; not sure what you mean
19:32:27  <bradleymeck>want to sniff all those auth headers people are sending? just modify OutgoingMessage!
19:32:28  <devsnek>yes web platform apis
19:32:37  <devsnek>like i said above, polyfilling/implementing web platform apis
19:32:44  <devsnek>that's definitely not a majority of users
19:33:28  <bradleymeck>devsnek: even if it is just node core locking down it would be nice, as right now we can't even do package isolation of tons of core since it has tons of mutable prototypes that we call instead of the original fns
19:34:09  <devsnek>i don't necessarily agree that it is a problem
19:35:08  <devsnek>my opinion of untrusted code continues to be "don't run it"
19:35:30  <bradleymeck>you can disagree, but my concerns remain. lack of concern on your part does not mean mine should remain unaddressed, if you have concerns with the consequences of addressing my concerns that seems like something we could work on, but as it stands i don't see a reason to drop my concerns
19:36:34  <devsnek>but if your concerns tie me down its the same problem
19:36:36  <bradleymeck>the point of a lot of work is to make it so that you can form an opinion on if code can be trusted
19:36:53  <bradleymeck>devsnek: what are they preventing?
19:37:30  <bradleymeck>you have been talking about a specific solution that goes against my concerns of safety, if you can alter your solution, that seems fine.
19:38:05  <devsnek>for example locking private data to class syntax
19:38:19  <bradleymeck>i'd love it to be outside of classes
19:38:31  <bradleymeck>i even have emailed people about `private #foo;`
19:39:10  <bradleymeck>nothing about the concerns over branding, partial initialization, etc. are being tied to class syntax
19:39:29  <bradleymeck>it is just the first place that got syntax for this stuff
19:40:36  <bradleymeck>class syntax has some nice thigns about the lifecycle of constructing instances that give it an explicit initalization point for private fields that gets around the branding and partial init problems
19:42:16  <bradleymeck>in theory if we make real refs for the field key you could also put the fields in object literals, since they also have an explicit point of init for branding, but there are some things about order of ops that would probably need to be discussed to avoid partial init.
19:46:55  <bradleymeck>an explicit initialization op like `private.init(o, #foo);` could be an interesting way to get around brand checking in a dynamic thing, where this operation would only be done when you are initially adding the field (semantics could have bikehshedding). However idk a good solution to partial init that Bakkot has concerns with
19:47:28  <bradleymeck>could initialize multiple at once maybe?
19:49:00  <bradleymeck>littledan: idk if these thoughts have any affect for class.initialize but just some minor thoughts on if it would be problematic outside of classes would be interesting
19:51:01  <devsnek>bradleymeck: my general understanding of js is that it's designed to be looseish by default
19:51:25  <bradleymeck>its far less loose than tons of languages
19:51:38  <bradleymeck>lack of reflection on scopes is a big one
19:52:36  <devsnek>I'd say it's loose where it can be, I don't think it's usually sought out as explicit features like that
19:53:07  <devsnek>branding isn't broken by having looser rules about private data
19:53:22  <devsnek>it just becomes the person who wants branding's job to brand it as they want
19:53:33  <bradleymeck>branding UX is broken since it defaults to problematic behavior
19:54:25  <bradleymeck>it is my point that the default of private behavior must not require programmer vigilance and boilerplate to be used correctly
19:54:43  <devsnek>I think we have different definitions of correctly then
19:56:40  * akirosequit (Ping timeout: 244 seconds)
19:56:57  * akirosejoined
19:58:14  <bradleymeck>I don't see much difference in usability with WeakMaps if the checks are required everywhere, you still need to use boilerplate to properly avoid the concerns we have listed above
19:58:39  <bradleymeck>those concerns are not removed by a desire for looser behavior in order to achieve a specific syntax
20:00:05  <bradleymeck>if you could figure out how to avoid those problems and keep your syntax desires that seems fine
20:00:41  <bradleymeck>adding an explicit init step (some fn or otherwise) mostly avoids the brand checking concern, but i don't have a good suggestion related to partial init
20:01:18  <bradleymeck>that would mean instead of having hasOwnProperty/in checks everywhere you would just perform the init when first giving and object private data
20:01:23  <bradleymeck>an*
20:09:38  <littledan>Yes, I have also chatted with people about private declarations outside of classes, and encouraged the committee to find a champion. Ultimately, I think we chose the right syntax for field declarations, though. It would be really annoying to type private all the time in the common case
20:11:37  <bradleymeck>littledan: I think #id is enough as long as we keep these "references" well understood
20:13:10  <bradleymeck>`{ private #id; (o) => o.#id }` seems sane to me where #id is kept contained within a lexical scope
20:16:11  <Bakkot>bradleymeck: the problem is, what does `{ private #id; class A { #id } }` mean?
20:16:13  <littledan>Sure, that seems fine
20:16:22  <bradleymeck>Bakkot: shadowed
20:16:36  <bradleymeck>same as other identifiers to my mind
20:16:39  <littledan>The tricky point is, when exactly is a new private declaration introduced, and when are you referring to an outer one
20:16:46  <littledan>There are many different designs possible
20:17:33  <bradleymeck>littledan: not sure i understand, how does this differ from other identifier shadowing?
20:18:15  <littledan>Also, if we use private to indicate introducing a new name, we can't use it in contrast to protected (as many people expect)
20:18:20  <bradleymeck>.#foo is a dynamic lookup to w/e the key #foo is anyway instead of some literal like a string named property
20:18:41  <littledan>One tricky case is, does an object literals introduce a new private scope or refer to the outer one?
20:19:02  <littledan>Another is, how should a class field declaration refer to an outer declared name?
20:19:07  <bradleymeck>littledan: are there people trying to push protected through? to my knowledge no one is trying to make the protected keyword do anything currently
20:19:12  <Bakkot>bradleymeck: a lot of the value in private #id declarations is in allowing two classes to share access to a private field without nesting which would not work without shadowing
20:19:23  <Bakkot>sorry, would not work with shadowing
20:19:40  <bradleymeck>Bakkot: how so?
20:19:43  <littledan>It's not that there is no answer to these questions, but there are many answers and someone would have to champion figuring out which is best
20:20:06  <littledan>Many community people miss protected, and the decorators story doesn't satisfy them
20:21:02  <Bakkot>bradleymeck: `{ private #id; class A { #id = 0; } let reflect = obj => obj.#id; reflect(new A); }` seems useful, but if the second `#id` shadows the first, that doesn't work; there's no way to write the `reflect` function except to put it in the class body
20:21:35  * keith_mi_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:23:56  <bradleymeck>Bakkot: [#id] = 0; given precedent with Symbols seems pertinent
20:24:28  <bradleymeck>though you could argue that it might not be needed that these work using fields syntax as well, and you just use the constructor
20:29:41  <bradleymeck>though cross module sharing is a big concern for me
20:29:59  <bradleymeck>cause exposing reflection fns is diff from giving direct refs to the fields
21:10:02  * keith_mi_joined
21:35:57  * jorydotcomquit (Ping timeout: 258 seconds)
22:04:24  * aki_joined
22:04:47  * akirosequit (Ping timeout: 246 seconds)
22:04:48  * aki_changed nick to akirose
22:17:21  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:24:38  * AtumTquit (Quit: AtumT)
23:08:14  * gibson042quit (Quit: Leaving.)