Pipeline Champions on 2022-03-18

02:28	<jschoi>	FYI: https://github.com/tc39/agendas/pull/1133
02:29	<jschoi>	(Please update https://github.com/tc39/agendas/blob/main/2022/03.md#schedule-constraints if you have schedule constraints and don’t want to miss the topic-reference bikeshedding, the bind-this syntax bikeshedding, or the holistic dataflow redux. ljharb, you have some constraints, so you might want to do so.)
02:49	<ljharb>	thanks, will do
02:49	<ljharb>	I’ll land your PR shortly also
03:35	<jschoi>	Just also made a community update: https://github.com/tc39/proposal-pipeline-operator/issues/232#issuecomment-1071995811
17:30	<jschoi>	I’ve come around to `#` as the topic reference again, even if tuple literals go with `#[]`. Requiring separation between topic and property access isn’t too bad: `x \|> (#)[0]`…since dynamically accessing the property of a topic is going to be strictly less common than using the topic reference itself. And it’s not really a “special case”…or at least it’s as much as a special case as requiring separation between `(^^)^y` or `(%%)%y`. Our candidates right now are `#`, `^^`, `%%`, `@@`, and `##`.
17:30	<ljharb>	in that case you'd do `(#)[x]` but `#.x` and `#?.[x]`?
17:30	<jschoi>	Yes.
17:31	<ljharb>	so it's only non-optional bracketed access that would need parens
17:31	<jschoi>	Leaving the `#[` token to be reserved for tuple literals.
17:31	<jschoi>	Yes.
17:31	<ljharb>	while in practice that's probably fine, that is an odd inconsistency
17:32	<ljharb>	i assume in Records, `#\n{` wouldn't be allowed
17:32	<jschoi>	Yes, I believe they are making `#[` and `#{` their own lexical tokens.
17:33	<jschoi>	https://tc39.es/proposal-record-tuple/#sec-punctuators
17:35	<jschoi>	Requiring parentheses to distinguish dynamic access `(#)[0]` from tuple `#[0]` is an odd inconsistency, I agree, but… The benefit of having a single- rather than double-character token (which would occur very frequently, every time a topic occurs) might be great enough to outweigh the cost of that inconsistency (which would occur relatively infrequently).
17:44	<TabAtkins>	Oh no, `#[0]` being a tuple by default is absolutely awful. Property access is going to remain far more common than tuple literals, forever.
17:45	<TabAtkins>	So long as tuples stick with `#[]` a single `#` for topic is verboten, imo.
17:45	<TabAtkins>	`(#)[0]` is, by itself, a substantially worse outcome than `##` everywhere for all other uses.
17:45	<TabAtkins>	(God, just typing it is awful - the hash and the parens are on different hands and all Shifted.)
17:51	<jschoi>	`(#)[0]` is, by itself, a substantially worse outcome than `##` everywhere for all other uses. Well, if we must have a two-character token (tuples are likely to go with `#[]` in the end), then I would rather have `^^` or `%%` than `##`…because, although topic references (and property access on them) may become more frequent than tuple literals…I expect tuple literals to be far more common than bitwise xor or remainder.
17:52	<TabAtkins>	All of these are fine with me; my weak aesthetic preference is still for `##` but I'm happy to stick with whatever the committee decides on.
17:53	<jschoi>	I suppose that saying “we can’t fully disqualify `#` until the tuple champions commit to `#[]` syntax” is tantamount to saying “we cannot advance pipe operator until tuples advance too”. Which would probably be Bad.
17:57	<jschoi>	(It’s still a shame that we can’t have a single-character topic though. 🥲)
17:58	<rbuckton>	(It’s still a shame that we can’t have a single-character topic though. 🥲) It's a shame we can't have an Identifier topic, imo. Double character isn't so bad, at least.
18:29	<jschoi>	https://docs.google.com/presentation/d/1dDucwsW8qM22yWLr_NHFmAiAltQSht3AXYW00kET4GA/edit?usp=sharing
18:33	<TabAtkins>	Slide 2's find() looks weird - it'd take an arrow function, surely, rather than constructing a comparison out of three strings?
18:34	<TabAtkins>	In all the examples those three args move as a unit anyway, so having them separate doesn't seem to be valuable for what you're showing off.
18:35	<TabAtkins>	otherwise +1
18:36	<jschoi>	Slide 2's find() looks weird - it'd take an arrow function, surely, rather than constructing a comparison out of three strings? Yeah, I took this code from this Firebase video about its new modular API (https://www.youtube.com/watch?v=r5eJQ3nPc6A). I’ll revisit the example and see if I can make it more compelling. Let me know if you have any ideas.
18:37	<jschoi>	I do think that arguments are an important part of reading order, and the fact that nested function calls require zigzagging of arguments is an important disadvantage of nested function calls.
18:37	<TabAtkins>	The code is reasonable otherwise, that's just a really weird set of arguments for a find() function.
18:38	<TabAtkins>	Just swapping that trio out for `x=>x.name == "fruit"` woudl work
18:38	<jschoi>	Yeah, good idea. I think I’ll replace it with `.find(pred)`.
18:38	<TabAtkins>	Sure, that works.
18:43	<jschoi>	And done. Thanks for the suggestion.
18:52	<TabAtkins>	Yeah, the 4-2-1-0-3-5 order really works now
22:27	<jschoi>	ljharb: I’m making slides for the bind/call-this operator plenary bikeshedding. I wanted to confirm your opinion—though you would block the pipe operator if bind/call-this did not advance, would you still block the pipe operator if Function.unThis advanced instead?
22:27	<jschoi>	I ask because Mark Miller had stated in the previous plenary that he is currently against any dataflow syntax proposal other than pipe operator to advance, but he is fine with functions (https://github.com/tc39/notes/blob/main/meetings/2022-01/jan-26.md#holistic-discussion-of-tc39-dataflow-proposals). So I am wondering what would happen if he stated that he would block any bind/call-this syntax…I would then pursue Function.unThis instead. Would this be acceptable to you as a substitute for a bind-this operator?
22:32	<jschoi>	https://docs.google.com/presentation/d/1-MLGCibETPX8NiIvNJ1xOxiMS-NB8GCbDGNcB5patiU/edit?usp=sharing
22:44	<ljharb>	ljharb: I’m making slides for the bind/call-this operator plenary bikeshedding. I wanted to confirm your opinion—though you would block the pipe operator if bind/call-this did not advance, would you still block the pipe operator if Function.unThis advanced instead? yes, i want a syntactic mechanism that restores receiver-first ordering. Function.callBind is just sugar for `Function.call.bind`, it doesn't really add much otherwise