00:17:20  <cloudshu>bterlson: i noticed that <li> don't have sensible right margins
00:27:46  * zsocjoined
00:31:30  <bterlson>cloudshu: who's to say what's sensible to li's???
00:34:06  <cloudshu>bterlson: are you saying it needs consensus
00:36:55  <bterlson>cloudshu: no, just joking, but what do you mean?
00:37:17  <cloudshu>sorry i didn't add enough ???s to convey i was also joking
00:37:57  <cloudshu>bterlson: i mean the right margin for text in <li> seems to extend past text in other tags
00:40:19  <cloudshu>bterlson: http://i.imgur.com/vAi2yA1.jpg the item under reads-bytes-from
00:41:07  * Fishrock123joined
00:46:09  * Fishrock123quit (Ping timeout: 255 seconds)
00:51:55  * Fishrock123joined
00:51:55  * Fishrock123quit (Remote host closed the connection)
01:06:55  * Fishrock123joined
01:21:43  * Fishrock123quit (Quit: Leaving...)
01:53:51  * not-an-aardvarkjoined
01:58:11  * gibson042joined
02:03:53  * gibson042quit (Ping timeout: 255 seconds)
02:19:03  * gibson042joined
02:35:01  * chicoxyz_quit (Remote host closed the connection)
02:35:36  * chicoxyzzyjoined
02:39:38  * chicoxyzzyquit (Ping timeout: 240 seconds)
03:07:36  * chicoxyzzyjoined
03:54:59  * chicoxyzzyquit
04:53:14  * jmdyckquit (Quit: Leaving.)
05:00:51  * gskachkovquit (Quit: gskachkov)
05:12:44  * abernixjoined
05:21:31  <littledan>hey, someone was saying, too bad we won't get `#{...}` for immutable objects if # is taken by private. If a syntax for immutable objects is a goal, how about `%{...}` for it? A nice thing about choosing a token to set off object syntax is, object literals are already an ASI hazard, so we could use an infix operator for it without causing any sort of additional ambiguity. Another option would be `^{...}`
05:25:32  <ljharb>just so i understand what the constraints are, can you elaborate on why `${}` wouldn't work, or `>{}`, or another char/identifier/operator?
05:58:21  * abernix_joined
06:01:37  * abernixquit (Ping timeout: 255 seconds)
06:17:47  * gskachkovjoined
06:19:22  * gskachkov_joined
06:19:22  * gskachkovquit (Read error: Connection reset by peer)
06:19:22  * gskachkov_changed nick to gskachkov
06:23:40  * gskachkovquit (Client Quit)
06:24:47  * gskachkovjoined
06:26:14  * gskachkovquit (Client Quit)
06:27:17  * gskachkovjoined
06:33:02  * gskachkovquit (Quit: gskachkov)
06:34:45  * gskachkovjoined
06:50:21  * gskachkovquit (Quit: gskachkov)
06:51:04  * gskachkovjoined
07:16:07  * abernixjoined
07:18:50  * abernix_quit (Ping timeout: 240 seconds)
07:50:29  <littledan>yeah, i guess an identifier "as a contextual keyword" such as $ would work just fine
07:50:59  <littledan>I'd worry a little about > because it might not throw an exception if you use it wrong
09:33:26  * abernixquit (Quit: Bye)
10:11:30  * gskachkovquit (Quit: gskachkov)
10:12:28  * gskachkovjoined
10:25:10  * mylesborinsquit (Quit: farewell for now)
10:25:40  * mylesborinsjoined
10:34:42  * chicoxyzzyjoined
10:37:27  * chicoxyz_joined
10:40:07  * chicoxyzzyquit (Ping timeout: 240 seconds)
11:35:05  * jmdyckjoined
11:43:34  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
12:00:48  * gskachkovquit (Quit: gskachkov)
12:02:21  * gskachkovjoined
12:40:16  * bradleymeckquit (Quit: bradleymeck)
13:01:06  * gskachkovquit (Quit: gskachkov)
13:02:01  * gskachkovjoined
13:53:35  * gskachkovquit (Quit: gskachkov)
13:56:41  * gskachkovjoined
14:39:57  * gskachkovquit (Quit: gskachkov)
15:00:45  * bradleymeckjoined
15:04:29  <ljharb>sure, any choice would be ideal to throw if used wrong
15:32:24  * gskachkovjoined
15:36:35  * gskachkovquit (Ping timeout: 240 seconds)
17:27:30  * gskachkovjoined
17:35:22  * bradleymeckquit (Quit: bradleymeck)
17:52:11  * gskachkovquit (Quit: gskachkov)
18:10:38  * bradleymeckjoined
18:13:37  * gskachkovjoined
18:48:20  * gskachkovquit (Quit: gskachkov)
18:51:12  * gskachkovjoined
19:05:05  <aklein>speaking of things that got deferred, a coworker was bugging me the other day about the fact that Arrays have this whole set of nice methods (map, filter, reduce). But if you switch to use Set you lose access to those. was there ever a concrete proposal about adding such methods for acting on iterators (or iterables)?
19:05:26  <aklein>I imagine it gets tied up in some circular dependency with builtin modules and `::`
19:05:41  * gskachkovquit (Quit: gskachkov)
19:10:19  * gskachkovjoined
19:31:29  <ljharb>aklein: there's not been a concrete proposal. it'd be awesome to add all those methods.
19:31:59  <ljharb>i have a proposal in mind that might address it, but it's like a year out before i'll have time to write it up. i'll pitch it to you in july :-)
19:40:37  <jeffmo_>ljharb: littledan: Why does private fields limit the ability to use `#{}`? It seems to be technically feasible still -- is it just that it looks too close?
19:41:14  * gskachkovquit (Quit: gskachkov)
19:41:41  * gskachkovjoined
19:43:54  <jeffmo_>aklein: IIRC that last time that was discussed it was lumped in with the need to apply a holistic "container" interface with these methods to *all* containers -- which gets pretty weird pretty quick. For example, what do `keys()` or `sort()` even mean on a Set?
19:48:08  <Domenic>So we think ^{...} is OK even though `5 ^ { foo: "bar" } === 5`?
19:48:33  <Domenic>Hmm no, I get it
19:48:50  <Domenic>5 { foo: "bar" } is already an ASI hazard so we can use ^
19:49:25  <Domenic>aklein: I floated ideas on that front a while ago, in particular adding them to Iterator.prototype
19:49:50  <Domenic>Then the syntax becomes something like map.entries().filter(...).map(...).collect(Map)
19:50:00  * gskachkovquit (Quit: gskachkov)
19:50:01  <Domenic>Which is not as nice as map.filter(...).map(...), to be sure
19:51:14  <Domenic>jeffmo_: my take would be treat everything as "array like" according to their default @@iterator, so maps are "arrays" of [k, v] arrays, sets are "arrays" of their values, etc.
19:52:41  * gskachkovjoined
19:53:27  <jeffmo_>Domenic: would someSet.filter() would return an array? Or a set?
19:53:45  <Domenic>jeffmo_: a Set seems reasonable
19:54:02  <jeffmo_>And someSet.sort() would return an array?
19:54:07  <Domenic>No, still a Set
19:54:11  <Domenic>Sets are ordered, remember
19:54:22  <jeffmo_>oh I didn't know that
19:54:31  <Domenic>Yeah they have a deterministic iteration order
19:54:42  <Domenic>(same for Maps)
19:56:03  <jeffmo_>ok, in that case I guess I can't think of any issue with it at the moment
19:57:12  * gskachkovquit (Client Quit)
19:58:04  <jeffmo_>I guess it sort of implies that any future container types we add probably need to be ordered as well
19:58:11  * gskachkovjoined
20:00:08  <Bakkot>we tend to get caught up in the design of the thing
20:00:45  <Bakkot>e.g. maybe it makes sense for these to be features people implementing other data structures could use, a la c++'s <algorithm>
20:01:00  <Bakkot>etc
21:08:03  <Domenic>Bakkot: that's where the dependency on :: comes in... without that nobody wants to put stuff in the language
21:36:20  <littledan>jeffmo_: Syntactically nothing; it might just be confusing semantically
22:10:01  <bterlson>I wish there were a way to do set equality without iterating over the entire set
22:10:24  <bterlson>although I guess with ordering equality might be a confusing property of sets?
22:12:10  <bterlson>{ equals(orderIsSignificant = false) => boolean } ?
22:14:54  <Domenic>That seems reasonable, although I want that for arrays too
22:15:23  <Domenic>(Also, { orderIsSignificant: false }, no boolean arguments please.)
22:17:37  <bterlson>yeah
22:17:41  <bterlson>ok
22:17:46  <bterlson>maybe I'll put this together
22:17:53  <bterlson>I've implemented set equality probably a dozen times since ES6
22:17:56  <bterlson>getting absurd
22:18:05  <bterlson>Array seems reasonable too
22:18:26  <bterlson>maybe `hasSameItems` or another more descriptive name is in order but that's for later bikeshedding ;)
22:21:56  <Domenic>The potential roadblock I see is squatting on the ".equals" name
22:22:17  <Domenic>If we ever want some kind of generic equality protocol (e.g. for Map keys/Set values) that seems like a prime candidate
22:49:59  <aklein>gsathya: ^^^ relevant to our discussion the other day
22:50:00  * bradleymeckquit (Quit: bradleymeck)
23:11:01  * chicoxyz_quit (Remote host closed the connection)
23:11:37  * chicoxyzzyjoined
23:14:58  * chicoxyz_joined
23:16:02  * bradleymeckjoined
23:16:05  * chicoxyzzyquit (Ping timeout: 240 seconds)
23:25:34  * gskachkovquit (Ping timeout: 255 seconds)
23:34:10  <bterlson>does it though if you will often need to parameterize whether ordering is important?
23:34:43  <bterlson>my usage in sets is 100% unordered but for arrays ordered may be the reasonable default
23:35:10  * chicoxyz_quit (Remote host closed the connection)
23:35:13  <bterlson>generic equality protocol would probably use a symbol anyway
23:35:38  <bterlson>similar also to `Symbol.matches` for the pattern matching protocol
23:37:51  * chicoxy__joined
23:38:32  * bradleymeckquit (Quit: bradleymeck)
23:39:55  <Domenic>Well the difference is people might call the generic equality protocol in normal code, not through syntax
23:52:32  * bradleymeckjoined
23:53:55  * zsocquit (Ping timeout: 268 seconds)
23:55:28  <bterlson>Any thoughts on this syntax: MatchExpression :: `match` [no |LineTerminator| here] `(` Expression `)` [no |LineTerminator| here] `{` MatchExpressionClauses `}`
23:56:13  <bterlson>hard to disambiguate with calls to a function named `match` but how bad is it really :-P
23:57:19  <Domenic>why not reuse switch?