00:05:18  * ebryn_joined
00:05:24  * devsnek_joined
00:06:30  * spectranaut_joined
00:07:38  * [dpk]joined
00:11:56  * devsnek_quit
00:12:01  * gcommerquit (*.net *.split)
00:12:01  * keithamusquit (*.net *.split)
00:12:02  * devsnekquit (*.net *.split)
00:12:02  * ebrynquit (*.net *.split)
00:12:02  * STRMLquit (*.net *.split)
00:12:02  * spectranautquit (*.net *.split)
00:12:03  * dpkquit (*.net *.split)
00:12:03  * saulh[m]quit (*.net *.split)
00:12:04  * joyeequit (*.net *.split)
00:12:04  * d_runquit (*.net *.split)
00:12:04  * bstoroz_quit (*.net *.split)
00:12:05  * shachafquit (*.net *.split)
00:12:06  * AtumTquit (*.net *.split)
00:12:06  * boazquit (*.net *.split)
00:12:07  * caitpquit (*.net *.split)
00:12:07  * ChanServquit (*.net *.split)
00:12:07  * [dpk]changed nick to dpk
00:12:07  * ebryn_changed nick to ebryn
00:12:32  * devsnek_joined
00:12:52  * keithamusjoined
00:13:51  * AtumTjoined
00:13:52  * boazjoined
00:13:52  * shachafjoined
00:13:52  * ChanServjoined
00:13:52  * caitpjoined
00:16:08  * pandemquit (Ping timeout: 260 seconds)
00:16:28  * devsnek_changed nick to devsnek
00:16:36  * gcommerjoined
00:16:36  * STRMLjoined
00:18:57  * rwaldronquit (Ping timeout: 240 seconds)
00:19:05  * rwaldronjoined
00:23:35  * M-IvanSanchezquit (Ping timeout: 255 seconds)
00:29:33  * pandemjoined
01:09:36  * AtumTquit (Remote host closed the connection)
01:19:17  * M-IvanSanchezjoined
01:28:34  * saulh[m]joined
01:28:34  * joyeejoined
01:28:34  * d_runjoined
01:28:34  * bstoroz_joined
01:28:42  * saulh[m]quit (Changing host)
01:28:42  * saulh[m]joined
01:28:49  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
01:30:55  * bradleymeckjoined
01:32:16  * saulh[m]quit (Ping timeout: 246 seconds)
01:32:49  * M-IvanSanchezquit (Ping timeout: 252 seconds)
01:37:36  * gibson042quit (Quit: Leaving.)
01:47:47  * saulh[m]joined
01:47:56  * saulh[m]quit (Remote host closed the connection)
01:54:26  * saulh[m]joined
02:22:01  * bradleymeckquit (Quit: )
02:41:17  * M-IvanSanchezjoined
04:16:03  * jwaldenjoined
04:36:03  * jmdyckquit (Remote host closed the connection)
04:53:55  * srl295quit (Quit: Connection closed for inactivity)
05:00:16  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
05:56:35  * jwaldenjoined
08:22:30  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:40:52  * keith_millerjoined
09:14:18  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
09:50:44  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:25:09  * mylesborinsquit (Quit: farewell for now)
10:25:40  * mylesborinsjoined
10:29:28  <littledan>ljharb: I didn't mean to criticize your intent, sorry just going on a tangent rant about how we should see our role in TC39 as a broad coordinating one
10:29:34  <littledan>devsnek: Oh, that makes sense
10:52:54  * JaseWjoined
10:52:54  * JaseWquit (Changing host)
10:52:55  * JaseWjoined
11:39:09  * keith_millerjoined
12:09:08  * jmdyckjoined
12:26:13  <zkat>https://github.com/tc39/proposal-pattern-matching/blob/latest/CORE.md#big-picture after a conversation with awbjs, I added a section to the pattern matching proposal that tries to clarify how I see this feature fitting into, and interacting with, the rest of the language and other upcoming features.
12:32:56  * AtumTjoined
14:01:59  * caridyjoined
14:04:57  * caridy_quit (Ping timeout: 240 seconds)
14:10:59  <jschoi>zkat: Could you elaborate what you mean by, “On the downside, this expression might well make the smart operators subproposal significantly more complex in practice...”? There is a link to a tweet, but it doesn’t really explain anything. It would look basically the same with the other pipeline proposals.
14:11:50  <jschoi>The one difference I can think of is that the autobinding of the topic reference to each clause of the `match` is an optional and hypothetical feature. Unfortunately the tweet does not explain that.
14:14:12  <zkat>Did you see the linked tweet? I think that does a pretty good job of showing worst-case
14:15:14  <jschoi>Yes, the tweet at https://twitter.com/rreverser/status/975767900895219712. The `match` example would look basically the same in the other pipeline proposals.
14:15:38  <jschoi>The one big difference I can think of is that the autobinding of the topic reference to each clause of the `match` is an optional and hypothetical feature. Unfortunately the tweet does not explain that.
14:16:09  <zkat>The match example would not involve the cognitive overhead of that # and how it interacts with stuff idk
14:18:51  <jschoi>Are you referring to the `match` clause autobinding? Because other than that, the other pipeline proposals would look the same, except they would wrap the `match` expression in an arrow function.
14:19:48  <zkat>I think this is just my bias because I find the smart pipeline proposal confusing and maybe a bit baroque
14:22:16  <jschoi>That is understandable. But in this case, the other pipeline proposals interact with the `match` operator in a similar fashion.
14:22:34  <jschoi>In the other two, using the old `match` syntax, it would instead look like `… |> f |> ($ => match ($) { 100: $, Array: $.length, /(\d)(\d)(\d)/ -> m: m.groups |> ($ => $[0] + $[1] + $[2]) })`.
14:22:54  <jschoi>That’s using the other pipeline proposals.
14:24:25  <jschoi>It’s understandable to find the smart-pipeline proposal confusing. But in the case of `match`, I don’t know if there is enough of a difference with the other proposals to specifically call it out.
14:25:24  <jschoi>Sadly, that tweet isn’t helping people’s confusion. It conflates the core smart-pipelines proposal with a bunch of hypothetical additional features.
14:26:29  <jschoi>I would be happy if the reference to smart pipelines in https://github.com/tc39/proposal-pattern-matching/blob/latest/CORE.md#big-picture were simply removed, or at least mentioned in the same breath as the other pipeline proposals without specific calling out. There simply isn’t much of a special interaction with `match` here.
14:27:56  <jschoi>Or, at least, there simply isn't an interaction between `match` and smart pipelines that is very different from the interaction between `match` and the other pipeline proposals. The latter is basically the same, except with more arrow functions.
14:28:55  <zkat>(in rerospect, btw, I feel like "baroque" was maybe more strongly worded than intended, sorry about that)
14:29:05  <jschoi>zkat: At the same time, thanks for your hard work on the `match`proposal, and thank you for writing this section.
14:29:19  <zkat>jschoi: I should just move it to the tagged literals section, which does interact with smart pipelines directly
14:29:57  <jschoi>Is the interaction with the choice of placeholder? Because I’m thinking of switching nullarly `#` to `%`. It’s just bikeshedding anyway, not a real semantic interaction.
14:30:02  <jschoi>Also, thanks.
14:30:11  <jschoi>*nullary `#` to `%`
14:44:55  <zkat>I share the sentiment of a lot of folks that having multiple proposals with glyph-based syntax extensions makes me uneasy :)
14:45:22  <zkat>(and I say that as someone who's making one of those)
14:51:55  <jschoi>That is understandable. Hopefully this particular proposal’s risks and benefits will eventually become clearer, once people are able to try it out in Babel. From playing around with real-world code, I think that it is worth it: in particular, it elegantly subsumes *another* proposal with another placeholder (rwaldron’s partial application and its `?`, which brings its own complexity). But if it ends up being not worth it,
14:51:55  <jschoi>then it’s not worth it.
14:52:06  <jschoi>zkat: Having said that, I just want to avoid misleading people about a special interaction between `match` and smart pipelines, where there isn’t any (at least compared to the other pipeline proposals).
14:52:24  <zkat>I think I'll be removing it :)
14:52:29  <jschoi>Thank you, gosh.
14:52:48  <zkat>sorry, I was reading more about the proposals just to make sure I wasn't missing anything
14:52:49  <jschoi>I’m rooting for your own proposal too, from here.
14:53:03  <zkat>I'm rooting for pipelines! I'm sure whatever we end up with will be handy.
14:53:04  <jschoi>Well, plural proposals, now, with tagged literals.
14:53:19  <zkat>tagged literals, and `as` patterns
14:53:27  <jschoi>Ah, right; three proposals, wow.
14:53:38  <zkat>(`const {foo: {x} as foo} = {...}`)
14:53:42  <zkat>yeah
14:54:03  <zkat>I mean. I just think they work a lot better when you can focus on them and see how they each interact with everything else
14:54:32  <zkat>splitting out the fancy destructuring improvements from match itself made the proposal much more streamlined, and made it much easier to see how it would interact with the rest of the stuff
14:55:27  <jschoi>Definitely agreed.
14:55:31  <zkat>I might retain the section about general pipeline interactions anyway just because it seems like a nice way to branch out different sections of the pipeline, without mentioning anything about smart ones in particular
14:56:36  <jschoi>As long as smart pipelines are not called out specially, it sounds good to me.
14:57:17  <jschoi>Looks like it’s already committed. Thanks again.
15:15:27  <zkat>np
15:38:00  * bradleymeckjoined
15:42:35  * bradleymeckquit (Client Quit)
16:35:38  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:48:25  * bradleymeckjoined
17:07:27  * JaseWquit (Quit: Leaving)
17:44:52  <devsnek>zkat: in the above example the final `foo` variable is an object with `x` from `{...}.foo.x` right?
17:45:36  <zkat>yep
17:46:28  * caridyquit (Remote host closed the connection)
17:47:00  * caridyjoined
17:47:09  <devsnek>the idea there is filtering other properties out of foo i guess?
17:47:32  <devsnek>i just get concerned 'cuz `as` is used in import which is already confusing enough for not being object destructuring
17:47:54  <zkat>the fact that import uses it is a big reason why people want it that way :)
17:49:38  * bradleymeckquit (Quit: )
17:51:28  <devsnek>what about like `const { x as y } = ...` vs `const { x: y } = ...`
17:51:35  <devsnek>are those interchangeable?
17:51:48  <devsnek>does `as` only work with aliasing destructures
17:52:24  <zkat>that's a different thing
17:52:42  <zkat>in the first example, `x` is `foo` itself
17:53:10  <zkat>like, it's the same syntax as the example you're giving, but with SingleNameBinding
17:53:36  <zkat>`const {x: x as y} = ...` is your example
17:53:56  <zkat>`const {x: {x} as y} = ...` is mine
17:54:04  <devsnek>yes i see
17:54:19  <devsnek>thats why i asked :p
17:54:46  <zkat>ah I get it. Yes, as you say. interchangeable.
17:55:30  <devsnek>thats slightly awkward although i do see the use
18:12:01  <zkat>it's a problem with current destructuring binding, where the closest thing to this you can do is double-up on properties, but it ends up being awkward.
18:12:25  <zkat>and when you add matching, the need to be able to say "I expect this, but I also want this other bit inside _that_" goes up
19:08:33  * AtumTquit (Ping timeout: 256 seconds)
19:10:59  * AtumTjoined
19:18:51  * caridyquit (Remote host closed the connection)
19:19:32  * caridyjoined
19:22:17  * jwaldenjoined
21:40:11  * gibson042joined
21:59:40  * AtumT_joined
21:59:56  * AtumTquit (Read error: Connection reset by peer)
22:26:44  * not-an-aardvarkjoined
22:41:37  * vikash-afkquit (Remote host closed the connection)
23:20:04  <devsnek>did the spec mandate these error messages being misleading af https://gc.gy/ħȳ.png
23:20:50  <devsnek>weird the top of the screenshot got cut off https://gc.gy/.png
23:46:54  * vikash-afkjoined