00:01:17  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:07:28  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
00:21:59  * keith_millerjoined
00:25:17  * isiahmeadowsquit (Quit: isiahmeadows)
00:28:56  <devsnek>petition to change ECMAScript to EASports on april 1st :P
00:39:44  * AtumTquit (Remote host closed the connection)
00:49:08  * isiahmeadowsjoined
00:53:12  * gibson042joined
00:53:39  <mylesborins>devsnek 😒
00:53:41  <mylesborins>😇
01:03:21  <devsnek>❤️
01:21:59  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:40:01  * not-an-aardvarkjoined
01:44:08  * bradleymeckquit (Quit: bradleymeck)
02:19:40  * isiahmeadowsquit (Quit: isiahmeadows)
02:26:53  * isiahmeadowsjoined
03:55:57  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
04:01:30  * jmdyckquit (Remote host closed the connection)
04:29:56  * keith_millerjoined
05:21:08  * gibson042quit (Ping timeout: 276 seconds)
05:30:14  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:15:18  * keith_millerjoined
08:30:59  * keith_millerquit (Remote host closed the connection)
08:31:43  * keith_millerjoined
08:35:32  * keith_millerquit (Client Quit)
08:39:40  * isiahmeadowsquit (Quit: isiahmeadows)
09:04:00  * keith_millerjoined
09:04:43  * isiahmeadowsjoined
09:50:04  * JaseW_joined
09:50:12  * JaseW_changed nick to Jayflux
09:50:12  * Jayfluxquit (Changing host)
09:50:12  * Jayfluxjoined
09:50:19  * Jayfluxchanged nick to JaseW
09:50:27  * JaseWchanged nick to Jayflux
10:16:58  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:25:09  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
10:33:20  * keith_millerjoined
10:39:24  * AtumTjoined
10:49:22  * bradleymeckjoined
10:51:42  * gibson042joined
11:07:35  <zkat>hey littledan can i take ur syntax plz: https://twitter.com/maybekatz/status/978948404352028672
11:07:42  <zkat>(I'd really like that #)
11:10:47  * Jayfluxchanged nick to JaseW
11:12:00  <bradleymeck>zkat: # seems a bit of an odd choice to me, ! seems nice to me (having come from places that use ! for macros/templates)
11:13:37  <bradleymeck>I know D and Rust use that, but not sure I've seen binary ! in other places
11:19:29  <zkat>bradleymeck: # has significant precedent
11:20:35  <zkat>I'm not sure how "everyone seems to use this for corresponding constructs" is an "odd choice" but
11:21:24  <zkat>as in, I can think of 5 languages that do that, off the top of my head, and I can probably find 5 more of them
11:21:35  <zkat>including C-like languages
11:21:47  <zkat># for private property access, otoh, is largely inprecedented?
11:21:49  <zkat>so
11:28:39  <bradleymeck>zkat: # is what JS is looking at for private, so using it for construction seems odd to me
11:29:11  <bradleymeck>I'm not sure I buy into other languages making stylistic choices for JS if it conflicts with other syntax
11:29:47  * jmdyckjoined
11:31:43  * gibson042quit (Quit: Leaving.)
11:47:39  <zkat>I don't intend to let private fields keep that syntax if this lands, so there's no conflict
11:48:05  <zkat>But if we want to reuse unaries, ~ could be read at "object similar to"
11:48:18  <zkat>Map~{}
11:49:23  <bradleymeck>zkat: what syntax did you have in mind for private?
11:50:24  <zkat>None
11:50:30  <zkat>🙊
11:50:31  <bradleymeck>also, there is still conflict until it gets changed and changing it would probably need a very similar sigil style
11:51:16  <bradleymeck>as long as it doesn't correlate to private I am not of strong opinion
11:58:55  * bradleymeckquit (Quit: bradleymeck)
12:05:02  * JaseWquit (Remote host closed the connection)
12:10:07  * gibson042joined
12:25:35  * gibson042quit (Ping timeout: 276 seconds)
12:51:07  <devsnek>I'm still a fan of private + ->
12:55:52  <devsnek>it also occurs to me that Identifier{ } isn't valid syntax right now
12:56:30  <devsnek>just asi hazard I guess
12:58:03  <devsnek>but I think the overall effect is rather appealing
13:02:28  * bradleymeckjoined
13:16:16  * pouwerkerkquit (Quit: Connection closed for inactivity)
13:20:16  <bradleymeck>devsnek: -> gets really awkward when you start thinking of `private #foo;`
13:20:35  <bradleymeck>outside of classes*
13:20:43  <devsnek>outside of classes?
13:21:00  <devsnek>and what is private #foo
13:23:19  <bradleymeck>it would allocate a lexically scoped #foo that you could use. sec, there isn't a real proposal yet but I can write example of what people have talked about
13:25:18  <devsnek>if the privates are lexically scoped that's cool
13:25:47  <devsnek>but since you have to use `this.#`
13:26:26  <devsnek>if they're just available as variables in the brackets if the class you can get rid of weird syntax on them
13:27:43  <bradleymeck>devsnek: https://gist.github.com/bmeck/baa8f21cb0b33d4c0db3aad05a38473a
13:28:00  <bradleymeck>devsnek: you can't put them into computed property stuff
13:28:12  <bradleymeck>cause that means they could be stored into variables
13:28:33  <devsnek>so like
13:28:44  <bradleymeck>you could share them across modules, but designs around that are still a bit fuzzy
13:28:48  <devsnek>why not just add a second Boolean param to symbol
13:29:10  <devsnek>called "totally hidden" true/false
13:29:29  <devsnek>that seems like a nicer approach
13:29:30  <bradleymeck>under the hood it could do that, but storing these in variables means they can leak to untrusted places
13:29:56  <bradleymeck>let me add an example of cross module sharing that would only let trusted things import the private
13:30:06  <devsnek>I get what you're saying
13:30:13  <devsnek>it just seems over the top
13:30:24  <bradleymeck>how so?
13:30:35  <bradleymeck>it acts quite different from a "value"
13:30:58  <devsnek>like creating new syntax to save js devs from making silly accidents
13:31:43  <bradleymeck>devsnek: well part of this came out from decorators having concerns with making a new PrivateName primitive type
13:32:04  <bradleymeck>it is very hard to make private fields not leak and have a good api
13:32:49  <devsnek>what happens when you use a private syntax on a proxy
13:33:00  <devsnek>no handlers fired I assume
13:33:31  <devsnek>that's the only benefit over some type of Symbol or PrivateName
13:33:40  <devsnek>that I can think of*
13:34:40  <bradleymeck>i'm not sure I understand how you could use the syntax on a proxy
13:34:57  <bradleymeck>just like other internal fields and why Proxy can't work with Promise easily it would not have the proper private fields
13:35:45  <bradleymeck>`new Proxy(Promise.resolve(0), {}).then(_=>_)`
13:35:50  <devsnek>I just meant like if the object happens to be a proxy
13:36:22  <bradleymeck>no handlers, yes
13:36:22  <devsnek>would you just be setting internal fields on the proxy object then
13:37:07  <bradleymeck>well if you are assigning, you would be assigning to the Proxy instance yea. if you are reading it would be an error if it doesn't exist
13:37:17  <bradleymeck>most likely... we could make it return undefined though!
13:37:35  <devsnek>undefined seems like the smarter choice
13:37:41  <bradleymeck>this is all fluff talk w/o someone willing to try and push through committee currently
13:37:50  <devsnek>although the big big question now
13:37:56  <devsnek>why this over a weakmap
13:38:54  <bradleymeck>easier to analyze, not needing goofy abstractions to prevent prototype mutation, static enough that it doesn't seem to always need a full real weakmap. Similar gains to PrivateSymbol
13:40:04  <bradleymeck>error on missing is attractive to me as well so that I don't do any accidental actions thinking something has a private field, but does not
13:40:17  <devsnek>well with your example
13:40:29  <devsnek>where you're keying objects given to you
13:40:41  <devsnek>it would be weird for them to throw imo
13:41:11  <devsnek>like object.#x ||= newid() would be impossible
13:41:31  <bradleymeck>it means you don't have to do the `in` check to see if something has a private field though
13:42:05  <bradleymeck>most of the time I would expect people reading the field to want to error if it doesn't exist
13:42:20  <devsnek>I would expect the opposite :p
13:42:31  <bradleymeck>initializing the field I think is a less common operation than reading
13:43:15  <devsnek>differentiating to regular property access seems like you're exposing implementation details about how js works
13:43:18  <devsnek>if that makes sense
13:47:14  <bradleymeck>it certainly doesn't act exactly like regular property access, certainly we can't support computed access either, so that already means we have a difference we can't resolve
13:47:29  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
13:48:02  <bradleymeck>-> and .# are more like new types of dispatch operators than property access
13:48:09  <bradleymeck>imo
13:48:14  <devsnek>I agree with the first
13:48:19  <devsnek>less so with the second
13:48:50  <devsnek>if it used the arrow I would feel ok with it throwing
13:48:58  <devsnek>lol that's weird
13:49:47  <devsnek>probs just cuz I'm used to -> from c++
13:50:24  <devsnek>bradleymeck: I think my hang up is that with .# the hash is part of the name as well when it's declared
13:50:34  <devsnek>so it just seems like regular property access
13:51:37  <bradleymeck>devsnek: we could also make this new thing just `private foo;`
13:51:44  <bradleymeck>and you can only get to it using # in various places
13:51:59  <devsnek>sgtm
13:52:04  <bradleymeck>at stage 0 everything goes
13:52:23  <devsnek>unicorn emoji for "magic accessors"
13:53:07  <devsnek>also tbh js having more and more static stuff feels kinda weird
13:53:20  <devsnek>not bad just weird
13:53:36  <bradleymeck>devsnek: being able to add private fields *after* an object is constructed is quite dynamic
13:54:03  <bradleymeck>less dynamic than `o[k]` certainly though
13:54:32  <devsnek>totally but i feel like we're also moving more into syntax than ever before
13:54:46  <bradleymeck>devsnek: oh drat I forgot, in order to do exporting we need it to keep the #
13:54:54  <devsnek>oh yeah that makes sense
13:55:13  <bradleymeck>devsnek: sadly we have had easier times passing syntax than APIs lately through committee
13:55:15  <devsnek>or just reuse the private keyword?
13:55:23  <devsnek>for exporting/importing
13:55:53  <bradleymeck>might be able to reuse private, but rewriting my examples I worry people will read `private foo;` as being able to be used like `o[foo]`
13:56:10  <bradleymeck>but syntax has been easier to pass because it often is tied to new kernel semantics
13:56:36  <devsnek>ye like right now adding a hash to that foo would make a lot of sense
13:58:36  <devsnek>honestly it's just the dot accessor that seems weird in this case
13:58:45  <devsnek>having the hash isn't that bad
14:06:00  <littledan>zkat I'll license you the syntax space but it's not coming for free
14:06:36  <littledan>see stupid sketches in https://github.com/tc39/proposal-extended-numeric-literals#extended-maparray-literals
14:06:52  <littledan>anyway I don't see an ambiguity if you overload # for this
14:07:10  <littledan>but, I really really liked Keith Cirkel's proposal for {# x: y #} for a frozen object
14:07:16  <littledan>and there's also the idea of #{ } for frozen object
14:07:41  <devsnek>two hashes feels like some weird evil templating
14:07:56  <littledan>it's important to consider the ASI hazard if we permit *both* the syntax sketch you have above *and* the prefix-less frozen object thing
14:08:33  <devsnek>is Object.freeze somehow lacking
14:09:50  <bradleymeck>i'm not entirely sold on frozen literals
14:10:12  <littledan>zkat: Also, consider with new literal syntax if you want to permit caching, like template tags do
14:10:14  <bradleymeck>freeze is a one time call
14:11:07  <bradleymeck>littledan: how would you do caching if you end up with something like Map#{[foo]: bar}
14:11:33  <bradleymeck>2 variables in different positions seems awkward
14:11:47  <littledan>well, I don't know what the proposed semantics of Map#{[foo]: bar} are, or the alternative that you're considering awkward
14:12:34  <bradleymeck>:p
14:13:07  <devsnek>when you guys are considering asi hazards
14:13:32  <devsnek>is the idea is like "behaviour X should never change no matter how many newlines are added" kind of thing?
14:14:23  <devsnek>like do you ever have cases where potential asi hazards aren't considered an issue
14:15:40  <littledan>I don't think of any of these things as absolute, but as costs and benefits to consider in a tradeoff
14:16:39  <littledan>we work together in TC39 to assess the weight of these different constraints. Comments on issues on repositories give us more data to work with in that assessment
14:17:13  <devsnek>just wondering if like Map{} and Set[] would ever be considered
14:17:34  <devsnek>very obvious asi hazard but nice looking
14:19:08  <littledan>actually, I don't know if it is; if the convention is to not put whitespace between the identifier and the bracket, maybe the ASI hazard isn't so bad
14:20:07  <bradleymeck>devsnek: there are 2 main locations of ASI hazards that we are trying to reason about most commonly as well so it might make sense to read https://github.com/tc39/ecma262/pull/1062/files . Identifier [ noLineTerminatorHere ] { could be possible but I need to think about member access as well. noLineTerminatorHere is the kind of ASI hazard I'm mostly fine with.
14:20:31  <devsnek>that's basically my thinking
14:20:52  <bradleymeck>the one where the next line mutates the previous' interpetation... that I need good reasons for if an alternative is easy
14:21:26  * bradleymeckquit (Quit: bradleymeck)
14:27:17  * bradleymeckjoined
14:27:52  <devsnek>I'm also wondering if this is a good opportunity for operator {}() and operator []()
14:35:31  * bradleymeckis scared
15:00:01  <devsnek>kek
15:06:19  <Domenic>I'm tentatively against Map/Set literals; parenthesis work pretty great.
15:06:32  <Domenic>New syntax does not pull its own weight in these cases
15:09:17  * mylesborinsquit (Quit: farewell for now)
15:13:47  * bradleymeckquit (Quit: bradleymeck)
15:16:17  <devsnek>i agree with the case of sets
15:16:31  <devsnek>but declaring a map with the arrays in arrays is pretty not fun
15:39:49  <Domenic>All alternative syntaxes are just about the same verbosity, and much harder to understand.
15:46:53  * bradleymeckjoined
15:47:15  <bradleymeck>Domenic: for pattern matching something to pass patterns back to some custom implementation does seem very appealing though still
15:47:37  <Domenic>Hmm I don't see the relation
15:49:55  <bradleymeck>the tweet this came from is making some crossover from pattern matching and class literals : https://twitter.com/maybekatz/status/978948404352028672
15:50:06  <devsnek>for pattern matching I'm using elixir/Erlang as my guide
15:50:38  <devsnek>elixir especially has it down to an artform
15:51:16  <Domenic>I see
16:23:13  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:23:52  * keith_millerjoined
16:29:09  * mylesborinsjoined
17:03:00  * bradleymeckquit (Quit: bradleymeck)
17:12:29  * cloudshujoined
17:20:58  <zkat>The point of the syntax is precisely to get consistency around a lot of language constructs and make pattern matching and destructuring nice and extensible.
17:21:09  <zkat>and enable some very specific patterns that both of those concepts use elsewhere.
17:21:27  <zkat>The construction syntax is the cherry on top, but it makes the destructuring bit more teachable, imo.
17:21:31  <zkat>learn once, apply everywhere
17:21:37  <zkat>(or `unapply()` if you will)
17:22:18  <zkat>If you can make it with `Map#{1: 2}` you can destructure it with `Map#{1: x}` or you can match it with `Map#{1: 2}`. pomf.
17:23:33  <zkat>devsnek: Erlang pattern matching (and, by extension, Elixir) is what I have the most experience with, too -- and this patmatch proposal is probably closest to Elixir, semantically, than anything else :)
17:24:13  <zkat>omg there's a lot of scrollback y'all. I was taking a nice stroll down the banks of the thames and I come back and tl;dr :P
17:24:23  <devsnek>lol
17:24:55  * isiahmeadowsquit (Quit: isiahmeadows)
17:25:35  <devsnek>zkat: was that tweet yours
17:25:52  <zkat>yes, I'm maybekatz of the internet
17:26:46  <devsnek>you must have good job security to have your twitter name be "too gay for this shit" hehe
17:27:37  <zkat>why?
17:28:36  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:28:58  * isiahmeadowsjoined
17:29:05  <devsnek>i dunno seems like something someone in hr wouldn't like for some reason
17:29:27  <zkat>why would hr have a problem with me being too gay to function sometimes
17:30:09  <devsnek>heck if i know, i just see stories on google news about people getting fired for social media stuff
17:30:43  <zkat>yeah well, doesn't stop the occasional idiot from emailing my employer asking to get me fired
17:30:49  * bradleymeckjoined
17:30:58  <zkat>but I'm not in this channel to talk about being queer, I'm here to talk about pattern matching~
17:31:09  <devsnek>pattern matching is nice
17:31:17  <isiahmeadows>hi
17:31:21  <devsnek>hello
17:31:50  <zkat>hi isiah!
17:31:54  <isiahmeadows>btw, i agree with you on pattern matching being nice.
17:31:58  <isiahmeadows>*you all
17:33:48  <zkat>I agree too
17:34:36  <zkat>I also think the tagged collection literal syntax is a superset of stuff like frozen objects, immutable objects, records, etc. I should probably write about all the things it happens to cover lol
17:34:52  <devsnek>whats wrong with Object.freez
17:34:53  <devsnek>e
17:34:56  <zkat>it's a lot of mileage for one character
17:35:03  <devsnek>ehhhhhhh
17:35:46  <devsnek>imo syntax should only be added when it provides a more explicit alternative
17:35:54  * bradleymeckquit (Quit: bradleymeck)
17:36:06  <devsnek>Object.freeze shows a lot more explicit intent than any syntax
17:36:23  * bradleymeckjoined
17:37:19  <zkat>Sure, but if someone wants to make a habit of freezing everything, `Frozen#{let: it, g: o}` is legit helpful
17:37:38  <zkat>see also, folks who user immutable.js being able to benefit from object literal syntax
17:37:41  <devsnek>const Frozen = Object.freeze
17:37:49  <devsnek>Frozen({ let: it, g: o})
17:38:36  <zkat>so, taking that into account, how do you feel about `new Object('let', it, 'g', o)` being the primary way of constructing objects?
17:39:30  * not-an-aardvarkjoined
17:40:30  <devsnek>i don't think thats a fair comparison
17:40:43  <bradleymeck>zkat: freezing is different from construction though
17:40:58  <isiahmeadows>zkat: reminds me of https://github.com/tc39/proposal-object-from-entries
17:41:01  <devsnek>the difference beteween Frozen#{} and Frozen({}) is one character :/
17:41:09  <devsnek>one or two
17:41:20  <devsnek>depending on if you're counting length or text diff
17:41:46  <zkat>devsnek: one character and, if you're using something other than a standard object (like a map), a complete inability to destructure it effectively.
17:42:35  <bradleymeck>i'm getting confused
17:42:46  <bradleymeck>are we talking about the literals or the pattern matching
17:42:57  <zkat>ok let's roll back
17:43:42  <devsnek>zkat do you just want a frozen thing that works on multiple types
17:43:57  <zkat>I had a bit of a puzzle trying to work out how to fit in some things that pattern matching is very very nice for, but there was no precedent in JS for (and would thus make adding directly to patmatch a bit of a wart, imo), and on top of that, I was having to deal with a grammar puzzle when I tried to write down the formal grammar for it.
17:44:18  <zkat>https://github.com/tc39/proposal-pattern-matching/blob/latest/TAGGED_COLLECTION_LITERALS.md I spawned off this _separate_ proposal that's meant to enhance the core match proposal (which is much smaller now)
17:44:21  <devsnek>i can understand wanting like System.freeze(object or map or set or whatever)
17:44:31  <devsnek>i don't get where adding new syntax comes into play
17:44:34  <zkat>devsnek: ok hold up
17:44:52  <zkat>Object.freeze is seriously a tiny microexample that I really don't care much for.
17:45:02  <zkat>it does not, itself, show the value of this.
17:45:38  <devsnek>collection literals sounds cool
17:45:40  <devsnek>i like the idea
17:45:48  <isiahmeadows>So, I'm starting to get a bit confused now...
17:46:06  <zkat>literally the only reason I mentioned frozen objects is because there's a separate proposal that tries to add literal syntax for them, and this would be able to slurp that up and we can forget about having more syntaxes for different things. I like shooting birds in a barrel like that?
17:46:30  <zkat>so let's set aside frozen objects if we're gonna talk about these literals :)
17:46:44  <devsnek>as long as no one is proposing adding syntax dedicated to freezing object literals
17:46:45  <devsnek>i'mok
17:47:35  <zkat>I literally am not doing that. I am saying that this happens to scratch that itch that some folks might have while solving a bigger thing
17:47:45  <devsnek>great :D
17:48:47  <devsnek>hmm from linclark's es modules cartoon today `The dynamically imported module starts a new graph, which is processed separately.`
17:49:02  <devsnek>isn't which graph a dynamic import puts modules in up to the implementor
17:51:17  <bradleymeck>technically yes, but fully explaining it in easy to read terms would be hard. I wouldn't want to write that up personally
17:51:42  <bradleymeck>the more that is written up as "host defined" the harder it will be for people to understand
17:51:49  <devsnek>ok
17:51:56  <bradleymeck>I think the point in the article was more about how Node and Web do things
17:52:00  <devsnek>just wanted to make sure i didn't have a misunderstanding of the spec
17:52:35  <bradleymeck>vm.Module certainly doesn't necesarrily follow those rules, nor does importing already loaded modules
17:53:24  <devsnek>vm.Module doesn't follow any rules :p
17:53:48  <isiahmeadows>:)
17:54:29  <rwaldron>Hey devsnek, this: '<devsnek> you must have good job security to have your twitter name be "too gay for this shit" hehe' is not appropriate for this channel. Please keep discussion on topic, which is defined here: https://www.ecma-international.org/memento/TC39.htm Thanks!
17:54:37  * bradleymeckquit (Quit: bradleymeck)
17:55:10  * bradleymeckjoined
17:55:18  <devsnek>rwaldron: sorry
18:05:01  <isiahmeadows>Could I get a few eyes on this set of mini-proposals of mine? https://github.com/isiahmeadows/array-additions-proposal
18:06:49  <devsnek>set looks good
18:06:56  <devsnek>reject seems pretty unneeded
18:07:50  <devsnek>insert seems nice i guess
18:09:20  <isiahmeadows>The only one unlocking any true features is `Array.prototype.set`, the other two being more nice-to-haves that are easily shimmed.
18:23:27  * jackhortonjoined
18:25:03  * isiahmeadowsquit (Quit: isiahmeadows)
18:26:18  * isiahmeadowsjoined
18:42:43  <bradleymeck>isiahmeadows: do we know if libraries already do things with those names? overall they seem fine to me .insert is the most appealing personally
18:44:32  <isiahmeadows>Only `.reject` is in libraries. I find it odd that `.insert` isn't, but `.set` is geared towards a memmove-style case, where you currently only see `for` loops used.
18:45:53  <isiahmeadows>I detailed in the proposals themselves where most of the relevant prior art is.
18:48:37  <isiahmeadows>The only one I strongly want is `Array.prototype.set` (and the rest I could live without if necessary).
18:50:45  <TabAtkins>V happy with `insert`, I always find `splice` inscrutable.
18:53:50  * srl295joined
19:04:31  <devsnek>i always have to check mdn for which argument is which with splice
19:04:37  * isiahmeadowsquit (Quit: isiahmeadows)
19:11:18  <jschoi>zkat: With regard to `#`, the stage-0/1 smart-pipelines proposal also proposes using `#` or `@` as a nullary operator. But as far as I can tell at first glance, this would be compatible with your proposed use of `#`. (It is compatible as well with private properties’ `#` too…I’m not sure about frozen-object literals; I need to check the grammar).
19:12:06  <zkat>the problem isn't whether the grammars will parse. They can be made to parse.
19:12:14  <jschoi>Visual confusion, right?
19:12:25  <zkat>the problem is having this glyph mean 20 completely different things in every context.
19:12:32  <jschoi>Right.
19:12:56  <jschoi>Just a heads up about yet-another-`#`-using-proposal, heh.
19:13:09  <jschoi>Though nullary `@` is still available…
19:13:11  <zkat>it's a rat race to see who gets that last common keyboard glyph for their pet feature at this point ;p
19:13:39  <zkat>likewise, using `@` for anything but decorators seems ill-advised.
19:13:48  <jschoi>We could always try opening non-ASCII Unicode syntax characters, ahaha. Yeah……
19:13:52  <zkat>(unless that proposal kicks the bucket)
19:17:33  <jschoi>For what it’s worth, related bikeshedding over pipeline placeholders has been occurring at https://github.com/tc39/proposal-pipeline-operator/issues/91, where issues like this have been considered with regard to smart pipelines and other pipeline proposals. `#`, `@`, `?`, `☃`, etc. (The snowman is a joke.) In any case, any use of `#` probably faces similar bikeshedding.
19:17:48  <jschoi>In any other proposal, that is.
19:18:27  <jschoi>Such a shame that the space of ASCII symbols is so tiny. Readability versus writability…
19:23:57  <ljharb>zkat: private's stage 3, # is off limits for anything else, since it'll be impossible to get consensus for dropping it
19:24:23  <ljharb>(imo)
19:25:04  <ljharb>(also i'd argue that truly private state is exponentially more important than collections at all, let alone collection syntax, but that's probably a longer debate)
19:25:33  <zkat>haha I consider private state to be extremely low priority for my interests, in general.
19:25:46  <zkat>it's one of those "sigh ok, as long as I don't have to do it you can have it" things for me
19:26:20  <ljharb>i mean, fair, but i think that's unlikely to be the case on the majority of the committee (and is definitely not the case for a significant percentage of the JS community)
19:26:24  <zkat>I've never really understood or found privacy useful in dynamic languages. It seems a bit too condescending for a language like javascript
19:26:39  <zkat>(not to mention, annoying in dynamic experimental contexts)
19:26:43  <ljharb>closures are JS's only privacy atm; they're super useful.
19:27:00  <zkat>privacy thinks the world exists exclusively in statically-execute text files
19:27:02  <ljharb>private fields are just performant and ergonomic per-instance closures
19:27:12  <ljharb>i mean, other than eval, doesn't it?
19:27:44  <zkat>no. In fact, I was hoping import would be a good push for JS towards workbench development.
19:27:52  <ljharb>i'm not sure what that means, can you elaborate?
19:28:03  <zkat>repl-based development on steroids
19:28:14  <zkat>the style of dev Lisp, Erlang, and Smalltalk support
19:28:32  <zkat>you keep a running image, incrementally write your program, trying things out and modifying them live.
19:28:49  <ljharb>hm - that sounds supremely untenable in a language that primarily runs on the web
19:28:59  <zkat>quite the contrary
19:29:09  <zkat>modern devtools get VERY close to this dev style
19:29:16  <zkat>it's one of the things I enjoyed about webdev the most
19:29:24  <zkat>I could just leave the debugger open
19:29:25  <ljharb>in dev, yes
19:29:27  <ljharb>but not in production
19:29:33  <zkat>workbench dev is for dev, not production
19:29:55  <ljharb>ok
19:30:12  <ljharb>so how would "for dev, not production" be a thing that's warranted to be baked into the language?
19:30:13  <zkat>(it does also become useful in production in some contexts, but that's more haphazard even in Lisp/Erlang)
19:30:38  <zkat>language design very much plays into whether a language can effectively be used in this dev style.
19:30:53  <zkat>it's not just a matter of throwing devtools at a wall and assuming they'll stick.
19:31:16  <zkat>you're still developing what's supposed to be in production
19:31:21  <zkat>you're creating production as you go along.
19:32:06  <zkat>if anything, tooling is what should add static semantics later and "freeze" the code. I prefer dynamic semantics in the core of the language, which is meant for human consumption, not for computers.
19:32:25  <bradleymeck>zkat: why would private prevent devtools from ignoring them? they already ignore various things like const
19:32:56  <zkat>I mean as long as I can access/add/remove/modify private fields from the repl, I'm fine with it :)
19:33:05  <zkat>but it doesn't sound like that's the intention
19:33:23  <bradleymeck>once you open devtools I don't think anything is off the table
19:33:31  <zkat>fair
19:33:37  <zkat>then why do you want private fields?
19:34:06  <zkat>like, what do they get you? If they're accessible for dev, and people can modify sources for convenience?
19:34:11  <bradleymeck>because I think it serves your users better https://twitter.com/bradleymeck/status/978769500068810752
19:34:32  <bradleymeck>._ is something that slowly makes internals treated as public features
19:34:43  <zkat>yeah
19:35:16  <zkat>and the actual examples that keep biting node folks because they decide to make them private involves features that were legit useful to the community and other people managed to add in because the language is dynamic enough
19:35:26  <ljharb>zkat: public is anything that's observable or reachable in production.
19:35:34  <zkat>instead of having to wait for Mt Olympus to bless them with features
19:35:35  <ljharb>zkat: iow, "undocumented" or "documented as private" is irrelevant
19:35:46  <zkat>yeah, that sounds great to me
19:35:48  <ljharb>if node is making things private that are useful, then those should be public
19:35:53  <bradleymeck>zkat: making a designed API and supported is better than telling them that using internals is a good way to approach things
19:35:58  <ljharb>but "let's stick an underscore in front!" does not private make
19:36:00  <zkat>I see literally no problem with having "nasal demons ahoy" for adventurous people.
19:36:10  <zkat>I'm not saying tell them to use it.
19:36:37  <zkat>I'm saying that if reaching into your private world lets people achieve their goals, and they're willing to take the risk with non-semver-managed internals, then go for it
19:36:42  <zkat>like, we _literally benefitted from this_
19:36:43  <ljharb>i don't agree
19:36:56  <zkat>and the argument against it seems to be "well i design things and i don't like that happening"
19:37:03  <ljharb>i think that by permitting them to take the risk, you're incurring the ethical responsibility for whatever happens.
19:37:17  <zkat>meanwhile, the entire ecosystem has been benefitting, because there is _not_ a better API
19:37:22  <ljharb>it's the author's fault if the code is misused, no matter how much you didn't want them to do it
19:37:27  <zkat>ljharb: it's an API, not human rights
19:37:29  <bradleymeck>zkat: I have a very different perspective. instead of working towards a forwards compatible safe API for a use case, using internals is not a good approach
19:37:48  <ljharb>i think they're a lot more similar than you're implying.
19:37:53  <bradleymeck>once you use internals you make your implementation more fragile as has been seen with custom fs reimplementations several times
19:37:53  <zkat>bradleymeck: I like treating programmers as consenting adults that can take care of their own business and suffer their own consequences.
19:38:14  <ljharb>zkat: "we're all adults here" is a policy that consistently proves to fail somehow, everywhere it's employed.
19:38:42  <bradleymeck>zkat: I think that is too simplistic, I think you have a responsibility to make your development robust so that people can be less afraid of using things
19:38:58  <zkat>ljharb: I don't think deviating from the scope of it and going into abstract ethics/morality is at all useful or appropriate here.
19:39:15  <bradleymeck>by treating people as responsible you are also taking on the responsibility of keeping your internals the same, which I heavily disagree with
19:39:18  <ljharb>we don't have to go down that road, but i think it's highly relevant and appropriate ¯\_(ツ)_/¯
19:39:34  <zkat>bradleymeck: and I do. I am entirely on board with documenting semantics, putting warning signs, and willfully breaking people who violate those boundaries.
19:39:36  <ljharb>if you're going to claim "condescending" then i get to point out that condescension isn't worse than acking that humans do bad things
19:39:47  <bradleymeck>zkat: I don't think warning signs are the way to go
19:40:08  <bradleymeck>if people want to break internals they can fork things pretty easily
19:40:26  <ljharb>forking is fine, then they're authoring the parts that can break.
19:40:28  <ljharb>(by exposing them)
19:40:40  <zkat>bradleymeck: then your privacy means literally nothing except added complexity
19:40:52  <zkat>and it presumes that you've foreseen the entire scope of what someone might do with your API
19:41:02  <bradleymeck>zkat: how so? if you fork my project I'm not beholden to give you support. you have to float your patches somehow
19:41:06  <zkat>see also: the actual value that shimming literally, actually, had for JS over the years.
19:41:06  <ljharb>no, it merely requires that people ask, to be able to do something unforseen
19:41:26  <zkat>the modifiability of the universe is a core feature of a language like JS
19:41:30  <bradleymeck>zkat: shimming public things is fine, not sure we can compate that
19:41:49  <ljharb>that's why it's so critical that individual software packages be robust against modifiability of the universe.
19:41:54  <zkat>and it's tremendously ambitious to think your designed API will cover needs in the size of ecosystem we have.
19:42:10  <ljharb>it doesn't have to cover all the needs. that's what feature requests are for.
19:42:17  <bradleymeck>zkat: if it doesn't cover needs, you add to it.
19:42:28  <bradleymeck>and you don't have to be as afraid of changing internals to add to it
19:42:46  <zkat>it just seems terribly paternalistic to go to such lengths to enforce privacy.
19:42:55  <bradleymeck>how is it paternalistic?
19:43:11  <zkat>"this specific API will never be useful to you"
19:43:39  <zkat>I mean, I literally yell at people all the time for trying to do `require('npm')` and trying to do stuff with it, but
19:43:46  <bradleymeck>"this specific API is an internal detail, if you need it exposed we can figure out how to solve your use case"
19:43:52  <ljharb>imo you're painting a false dichotomy between "everything is permitted" and "you can't do anything i don't let you". encapsulation allows the author to have more nuance on that spectrum.
19:44:02  <zkat>those specific APIs have enabled some tremendous support tooling in Node
19:44:23  <bradleymeck>zkat: imagine if we had publicly exposed hooks to do that instead?
19:44:35  <zkat>ok then design them so people can move to those
19:44:37  <ljharb>and imagine how tremendous it'd be if those APIs had official support, instead of the current situation since npm 3 where the JS APIs break in non-majors all the time and are undocumented and unsupported
19:45:00  <bradleymeck>zkat: if they already rely on internals isn't it too late? why would they update until it breaks (see Buffer)
19:45:10  <bradleymeck>that one isn't even internal
19:45:10  <ljharb>that's not npm being magnanimous and enabling use cases, it's a sloppy accident that could have been intentional and elegant.
19:45:41  <zkat>this idealism is exactly why I think privacy is a mistake
19:45:52  <zkat>I agree entirely that having proper APIs is wonderful!
19:45:57  <zkat>but that's not how writing software works
19:46:01  <zkat>I'm not prescient
19:46:09  <zkat>how egotistical of me would it be to assume I am
19:46:09  <bradleymeck>i see it as encouraging communication and avoiding footguns, how is it idealism?
19:46:28  <ljharb>you don't have to be. it's simply saying that people have to *ask* so that an API can fit their use cases
19:46:38  <zkat>because I'd like people to not have to bend over backwards to get things done more than they already are.
19:47:06  <zkat>sometimes, people pull off things you wouldn't imagine
19:47:08  <zkat>that's super valuable
19:47:14  <zkat>I'd rather keep that ability, even if it's ugly sometimes
19:47:23  <ljharb>they can do that with PRs.
19:47:40  <zkat>sure, and they can also solve their problem themselves.
19:47:40  <bradleymeck>i don't think asking for a feature/moving forward with a PR is any more burden than learning how internals work and then relying on them
19:48:03  <bradleymeck>privacy encourages exposing under served usecases, it isn't just a gate keeping mechanism
19:48:06  <zkat>so my point is privacy features are this... strange power move on the side of developers
19:48:15  <zkat>but tool devs aren't the one running the code
19:48:16  <zkat>users are
19:48:20  <zkat>let them do for themselves what they will
19:48:30  <ljharb>developers already have that power with everything but instances
19:48:41  <zkat>let them have it with instances, and we're covered
19:48:42  <ljharb>this is just filling in the gap.
19:48:46  <ljharb>yes, that's what private state is
19:48:49  <zkat>it just all seems terribly pointless
19:48:49  <bradleymeck>i don't understand the "users" bit, sure they are the ones running a process but they can always fork things too?
19:48:55  <ljharb>private fields, rather
19:49:09  <zkat>bradleymeck: why should they fork when they can patch?
19:49:25  <bradleymeck>zkat: so that other people can install it
19:49:27  <zkat>like, why is it that important to raise the bar like that?
19:49:38  <zkat>other people can still install your original
19:50:06  <bradleymeck>well you forked it because you are using unsupported things, that raises the bar already?
19:50:27  <zkat>eh, you can usually get away with it for a while. That's good enough for me ;)
19:50:50  <bradleymeck>using internals means you learned the internals already as well, why are people wanting to keep using internals rather than progressing the library to publicly handle things?
19:50:56  <zkat>"why can't I do this?" "because I don't wanna let you" "but I could, if you weren't making that choice for me. The code can do it" "I don't want you to"
19:51:07  <zkat>^ I reeeeally am not into this attitude
19:51:15  <bradleymeck>I would hope it is never "because I don't wanna let you"
19:51:17  <zkat>go ahead and progress your externals
19:51:24  <zkat>and then tell people to move off the private one
19:51:28  <zkat>and when you have an equivalent, break 'em
19:51:47  <bradleymeck>thats a major breaking change, vs just making the public use case one time
19:51:49  <zkat>privacy is _literally_ "because I don't wanna let you"
19:51:55  <zkat>but it gets even worse when you leave open source
19:52:07  <zkat>now you're taking on that attitude at a very small scale, with your own coworkers
19:52:08  <bradleymeck>zkat: I *heavily* disagree and would take offense at that sometimes
19:52:11  <zkat>that's so territorial
19:52:23  <bradleymeck>sometimes I'm still developing internals but am publishing things
19:52:24  * Fishrock123joined
19:52:36  <bradleymeck>the more people rely on internals the less I can refactor during those times
19:52:56  <zkat>ok
19:53:05  <zkat>please do your best! 🎉
19:53:22  <zkat>(sorry, that was more sarcastic than is appropriate)
19:53:43  <zkat>the point is, this all feels like bending over backwards at the _expense_ of the people running the code, not their benefit.
19:54:24  <zkat>and I think a language should be designed for empowering users, not swatting their hands from across the internet at them because you have your own opinions about something.
19:55:00  <bradleymeck>I only see _expense_ if people don't communicate, right now we have existing expense because people harden internals to the point that they cannot change
19:55:23  <ljharb>devs are users too
19:55:36  <bradleymeck>I want people to communicate about when things are sub optimal, not create cliques of tribal knowledge around internals
19:55:44  <zkat>privacy is designed to be user-hostile. So no, I'm still not okay with it as a concept.
19:55:46  <ljharb>as an author, i am empowered when i'm able to improve my library without breaking people.
19:55:54  <zkat>I'd rather _devs_ bend over backwards if they want to inconvenience their consumers
19:55:57  <bradleymeck>zkat: I do not see it as user-hostile
19:55:58  <ljharb>it's not user-hostile to prevent people from doing things they shouldn't be doing in the first place.
19:56:06  <zkat>and we already have enough tools to allow devs to bend over backwards to do that.
19:56:09  <zkat>it seems enough for me
19:56:22  <bradleymeck>zkat: users are the people who run applications more than the people writing code
19:56:33  <zkat>I think deciding that you get to decide for people what they're allowed to do when the code makes it possible _is_ user-hostile
19:56:49  <ljharb>that's literally what being a library author is
19:56:50  <zkat>bradleymeck: tell that to browser plugin users.
19:57:07  <ljharb>otherwise the user would just write the abstraction themselves, since the language already allows it
19:57:10  <devsnek>is this an argument about privates being user hostile
19:57:11  <bradleymeck>library and application authors differ but both are valid users, but people running applications are different as well. we need to respect *all* of them
19:57:24  <zkat>ljharb: lacking code paths is not the same as specifically banning superficially-usable things.
19:57:44  <bradleymeck>zkat: we already have privacy from closures, I don't think we should make those public either
19:57:44  <devsnek>i think the most important part of designing a library used by people is api design
19:57:50  <zkat>I'd rather devs pay a serious price if they wanna get into consumers' business like that.
19:58:00  <ljharb>zkat: if privacy is doing nothing except hiding something that's otherwise usable, then that thing should surely be exposed or in a separate package. but that's rarely what it's doing.
19:58:09  <zkat>bradleymeck: I already eyeroll at people using closures to do information hiding.
19:58:23  <ljharb>devsnek: agreed! but your API is "everything that can possibly be seen or done" of your library.
19:58:29  <devsnek>indeed
19:58:39  <devsnek>thats why privates are important
19:58:46  <bradleymeck>zkat: that seems fine on a personal opinion, but I think we have real arguments about why privacy can be good for both authors and consumers
19:59:02  <zkat>this is like, deeply against what I see as the things that have made JS succeed on the web (the ability to openly access and manipulate the application world)
19:59:23  <devsnek>node.js as an example has a ton of underscore property baggage
19:59:30  <zkat>I have real arguments about why it's really discomforting to see this much effort being put into this sort of thing
19:59:34  <ljharb>that's not the only things that have made JS successful
19:59:49  <devsnek>arguably v8 is also very successful
19:59:50  <ljharb>and in fact, the ability to lock things down via closures is one of the *huge* reasons JS has been successful
19:59:51  <bradleymeck>zkat: internal slots have long been part of JS, I'm not sure we ever had full access to all things
20:00:13  <ljharb>modules themselves are a form of privacy, because they have a scope
20:00:16  <zkat>ljharb: when a form breaks in my browser, I pop up the debugger and fix it, and it works, because the code and data are open for access. For non-programmers, this manifests as installable user scripts.
20:00:21  <zkat>privacy is _hostile to that use case_
20:00:26  <ljharb>yes, that is true
20:00:31  <ljharb>so are closures tho. and modules.
20:00:38  <zkat>it's like adding built-in obfuscation to the language (it is literally obfuscation)
20:00:44  <ljharb>and that's a good thing, because then sites get far less bug reports about extensions breaking their site.
20:00:53  <zkat>modules are super nice because you _can_ dynamically modify them!
20:01:08  <devsnek>the amount of effort devs in js go to to hide stuff without privates
20:01:08  <ljharb>not after it's been imported, afaik
20:01:31  <devsnek>i think the #1 usage of WeakMap is polyfilling private properties
20:01:32  <zkat>like, I'm super stoked about how the module semantics can theoretically let me reload a module file and continue using it normally in a running application, with different internal code (in most/many cases)
20:01:35  <bradleymeck>zkat: what do you mean modify them?
20:01:44  <ljharb>theoretically, but that's not actually possible atm
20:01:48  <bradleymeck>hot reloading isn't possible in the current spec
20:01:54  <zkat>closure-style modules screw you over on the dynamic side of things at a deep conceptual level
20:02:05  <ljharb>and any API that makes it possible would never fly unless it also had a way to *lock down* a module from letting that happen
20:02:09  <zkat>esm lays the groundwork for you reloading things interactively
20:02:12  <devsnek>a es module is already a closure
20:02:23  <ljharb>so is a CJS module.
20:02:25  <bradleymeck>zkat: I'm not sure I understand that
20:03:07  <bradleymeck>you would have to replace all the bindings that a Module Record has linked to other modules which could invalidate a bunch of things like reference identity
20:03:24  <ljharb>hot reloading has tons of weird edge cases in the react world due to that.
20:03:45  <devsnek>in theory as long as you don't change the namespace shape you could implement an engine that lets you change the source
20:03:52  <devsnek>it sounds super dangerous and fragile tho
20:04:08  <zkat>bradleymeck: if you have `import {frobIt} from './my-cool-thing.js'`, and then you have your code calling `frobIt()`, and you're working interactively, you can go and rewrite `frobIt` in `my-cool-thing.js`, reload the file, and the reference to `frobIt` can (on a certain conceptual level) be replaced by the loader on the fly.
20:04:30  <ljharb>zkat: not if someone's done `const f = frobIt` tho, because then the binding isn't live anymore.
20:04:35  <zkat>like, this isn't pipe dream stuff. This is a super productive mode of development available to existing languages that works very well
20:04:38  <ljharb>live bindings would have to be viral for that to actually work out
20:04:41  <bradleymeck>with devtools you could do that, but JS itself doesn't expose such possibilities
20:04:42  <zkat>ljharb: correct, it doesn't and that's fine.
20:04:54  <zkat>reality is people who do this style of dev become well aware of that.
20:05:01  <ljharb>zkat: so then you get a bunch of weird edge cases where some things have the old frobit and some things have the new one
20:05:19  <ljharb>right, so now you're hugely constraining how someone can write code in order to get the benefits you're alleging
20:05:19  <bradleymeck>most of these sound like you just want to use devtools instead of w/e code editor you currently are using
20:05:21  <zkat>bradleymeck: I'm fine with that level, but this becomes significantly harder when you're assigning module values directly to lexical variables.
20:05:23  <devsnek>you would have to track the relationship between every variable assignment throughout the entire lifetime of theapp
20:05:27  <zkat>at least semantically very weird.
20:05:39  <ljharb>`promise.then(frobIt)` breaks the liveness too
20:05:40  <zkat>devsnek: nah
20:05:47  <devsnek>const x = frobIt
20:05:53  <devsnek>const y = x
20:05:57  <zkat>ljharb: promise.then(() => frobIt()) does not :)
20:05:58  <devsnek>const z = { y }
20:06:00  <ljharb>as does `frobIt.bind()`
20:06:07  <zkat>devsnek: see above comment about people being aware of it
20:06:07  <devsnek>what the hell is the value of z.y
20:06:14  <devsnek>if frobIt export changes
20:06:16  <ljharb>zkat: sure, i agree you can write code to preserve it. but that's cutting out a large part of how JS works, just to make hot reloading work
20:06:20  <zkat>ljharb: .bind "sounds like a you problem, not a me problem" :P
20:06:23  <ljharb>lol
20:06:28  <ljharb>it's a TC39 problem.
20:06:31  <ljharb>and a browser problem.
20:06:33  <bradleymeck>devsnek: devtools already has ways to locate all the variables/properties holding a specific value
20:06:48  <ljharb>iow the language already prohibits holistically solving the use case you want.
20:06:50  <bradleymeck>I don't see why it couldn't let you do a replace
20:07:06  <ljharb>you can always constrain yourself to a subset, but that's not something that's tenable from a language design or environment design level.
20:07:29  <bradleymeck>ljharb: the language does from spec but devtools and a good editing UX is the point here I think
20:07:41  <zkat>I don't really know enough about the actual defined mechanics of modules but it sounds like they were designed to prevent a use case I would've loved to have. Oh well.
20:07:44  <zkat>anyway
20:07:51  <bradleymeck>devtools work outside of spec all the time since they are power tools
20:07:54  <zkat>tl;dr I like dynamicity and the more open the world is, the better.
20:08:13  <zkat>I can live with the fact that other people prefer to lay down the law
20:08:15  <zkat>shrug
20:08:19  <bradleymeck>zkat: mind if I open an issue about find/replace and take up a few of your time as I try to refine it
20:08:36  <zkat>bradleymeck: about the what bit?
20:09:16  <bradleymeck>find all variables/properties with a value $foo , replace all locations with new value $bar
20:09:27  <bradleymeck>chrome devtools *can* do this, but there is no UI to do so
20:09:34  <zkat>that sounds like so much effort, but go for it :)
20:09:43  <zkat>I'm probably too used to languages that make this easy
20:09:45  <bradleymeck>not as much effort as it sounds like but not trivial
20:09:50  <zkat>ETOOSPOILED
20:10:05  <ljharb>so separately, that tagged collection thing, could that be a separate repo instead of inside pattern matching? or is it related
20:10:18  <zkat>Erlang and CL, the two main languages I've done this in, have this sort of thing pretty well cooked into their package/module designs.
20:10:29  <zkat>not that they have the best module designs :)
20:10:35  <zkat>but it's a thing they designed _for_
20:10:43  <zkat>and within that universe, works p well
20:11:04  <zkat>ljharb: I'll probably move it to a separate repo later. It's in there because I refactored it out today.
20:11:17  <ljharb>gotcha, i didn't realize it was in the pattern matching doc in the first place
20:11:34  <zkat>I was trying to cut down the regular `match` proposal to what I think is the minimal spec that works off existing language syntax/semantics as _closely_ as possible.
20:12:04  <zkat>ljharb: they were originally described as extractors, and were not a generalized concept -- they were meant to be specific to `match`
20:12:28  <zkat>and then I realized the feature would be way better if it was a general concept around literals, rather than this magic incantation in match
20:12:40  <zkat>unifying the concepts felt very elegant :)
20:14:31  * jwaldenjoined
20:14:35  <ljharb>hm, ok, i'll have to reread it, thanks
20:15:18  <zkat>you can safely ignore tagged collection literals for the time being
20:15:47  <zkat>there is literally nothing of substance that can be commented on right now.
20:16:13  <zkat>besides a very very general consideration of the concept but that's probably premature, too.
20:21:03  * Fishrock123quit (Read error: Connection reset by peer)
20:21:17  <ljharb>kk
20:22:03  <zkat>the pattern match proposal is doing alright, though. I very much plan on polishing it up a bit more and making some Executive Decisions™ about some bikesheds and then throwing it at the committee in May. I've already got a 60min slot for it 😁
20:22:45  <zkat>and once that one's in stage 1, it feels more justifiable to put serious work into the sub-proposals idk
20:25:04  <ljharb>i'd recommend not making too many executive decisions at this early stage
20:25:07  * tobiejoined
20:25:30  <ljharb>i find that effective presentations state all the bikesheds along with a strong preference, or at least open with the preference but then casually mention the bikesheds :-)
20:25:47  <ljharb>but either way i look forward to the agenda item :-D
20:28:07  <zkat>early stage sounds like exactly the time to make all the executive decisions, tbh
20:28:26  <ljharb>maybe so
20:28:39  <zkat>I prefer "define the optimal, bait with bikesheds"
20:28:55  <ljharb>i guess it depends on whether the "things decided against" are things that are likely to be asked about in committee anyways or not
20:29:09  <ljharb>(obv this only applies to bikesheds, ie, there's no strong technical argument one way or the other)
20:29:16  <zkat>the psychology of people wanting to have opinions is... fascinating and also something that I think needs conscious management in committee environments 😁
20:29:40  <zkat>(as someone who came to programming from the arts, and dealt with a lot of bureaucracy related to that in school)
20:29:58  * Fishrock123joined
20:30:05  <zkat>lemme tell you about helicopters some time.
20:30:07  <devsnek>are there any js types that don't have some sort of spiritual equivalent in c++
20:30:23  <devsnek>symbols maybe?
20:30:36  <zkat>Symbols are enums for dynlangs :)
20:30:55  <devsnek>huh
20:31:00  <zkat>dynamic languages
20:31:05  <devsnek>no the first part
20:31:10  <zkat>they're enums
20:31:13  <ljharb>enums of one?
20:31:49  <devsnek>how is a symbol an enum
20:31:54  <devsnek>maybe an enum member?
20:31:57  <zkat>I mean, symbols are kinda workhorses in a lot of languages that have them, but they often boil down to enums lol
20:32:09  <zkat>yes, _members_ of enums. Individual values.
20:32:25  <zkat>"here's a random thing that's kinda unique that you can check against"
20:32:49  <devsnek>I guess that makes sense
20:32:58  <zkat>they're no different than `const MY_CONSTANT = Object.create(null)` on that front
20:33:22  <devsnek>I'm trying to think of how to express an implementation for my whatwg proposal in a c++
20:33:48  <devsnek>maybe the proposal would be better for tc39
20:36:39  <devsnek>oh and undefined vs null I guess
20:47:31  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
20:50:21  * keith_millerjoined
22:34:06  * tobiequit (Quit: Connection closed for inactivity)
22:48:46  * Jayfluxjoined
22:57:10  * bradleymeckquit (Quit: bradleymeck)
23:10:40  * Fishrock123quit (Remote host closed the connection)
23:27:06  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:27:08  * Jayfluxquit (Quit: Leaving)
23:34:59  * Fishrock123joined
23:45:54  <Bakkot>I see we had the reflection vs encapsulation debate again today
23:49:23  * Fishrock123quit (Remote host closed the connection)
23:50:07  * Fishrock123joined
23:50:13  * Fishrock123quit (Remote host closed the connection)