Pipeline Champions on 2022-02-15

05:41	<rkirsling>	clearly we just need to sink decorators once and for all and reclaim @ 😉
05:49	<rkirsling>	but since that's sadly not going to happen, I'd suggest `#_`; if we can't use # or @ alone then we're clearly dead in the water on single-character solutions, but the ideal solution if we were starting from scratch would obviously be `_`. so if we've been tending to use # as a sigil for stuff lately then it seems reasonable to sigilize `_`. presumably this doesn't cause any problems since `#_` would only be currently valid as an `in` LHS
16:02	<jschoi>	Are there plans to ever allow unqualified private fields, like `1 + #x`?
18:00	<Ashley Claymore>	Are there plans to ever allow unqualified private fields, like `1 + #x`? I believe not as that would make '`#x in v`' ambiguous.
19:44	<ljharb>	That was explicitly decided to never be an option as part of private-in
19:44	<ljharb>	but also, nonzero people would have prevented that from happening anyways, because not all field access is on the receiver.
21:44	<jschoi>	Being reminded that private fields are always qualified—and that `#_` is an option—has made me somewhat less averse to `##`, funnily enough. As long as we’re making `#` into a ‘syntax dispatch’ token, maybe `##` or `#_` wouldn’t be too bad even when mixed with tuples/records…but `##` at least is still “heavier” and “noisier” than `^^`.
21:45	<jschoi>	`… \|> f(#[##])` / `… \|> f(#[#_])` / `… \|> f(#[^^])` is going to be real, and it’s going to be common.
21:58	<ljharb>	jschoi: `x \|> #y in #` isn't all too bad, to be sure (with `#` or `##`)
22:12	<TabAtkins>	Worst-case syntax confusion so far would be `#[##.#x]`
22:13	<TabAtkins>	which imo is sufficiently okay? There's always non-`#` tokens between the `#` that help break up the visual flow.
22:13	<TabAtkins>	(The only reason I'd object lightly to `#_` is they're on opposite hands and both Shifted, so I've gotta do a little dance when typing it.)
22:34	<jschoi>	Worst-case syntax confusion so far would be `#[##.#x]` Yeah. Though my concern isn’t syntax confusion so much as visual noise, glyph-recognition speed, and cognitive burden during rapid code scanning by human eyes. Although it is true that the `#`s are slightly broken up by `[` and `.`…they’re all going to blur together while you’re scanning through a big module.
22:34	<jschoi>	jschoi: `x \|> #y in #` isn't all too bad, to be sure (with `#` or `##`) With regards to `#` topics, I wish `#` topics were possible, but `#` topics are not possible if `#[]` syntax is used for tuple literals. (That’s why I had been asking about `@[]` tuple literals, but it seems like Committee opinions may be cool towards that.)
22:35	<ljharb>	ah, true enough