Pipeline Champions on 2022-01-08

00:01	<TabAtkins>	I don't think I'd have said they were different? I could be wrong, but if so, past me was incorrect. ^_^ The concerns are identical.
00:01	<jschoi>	(See also WH’s comments in https://github.com/tc39/notes/blob/master/meetings/2020-11/nov-19.md#extensions-for-stage-1)
00:02	<TabAtkins>	WH: Looking at the longer term consequences if we adopted this: This is mutually exclusive with a pipeline operator. I definitely do not want both in the language. I also see this as not really solving any significant problem. It does not define extension methods because, as you found out, you cannot use the same syntax for regular methods and what you're calling extension methods. So these aren’t really extension methods, but this does create a rift in the ecosystem where some folks will adopt the convention of defining methods in the :: namespace and some folks will adopt the convention of using functions, and there will be lots of unnecessary friction around the boundaries. I see that kind of thing as being harmful to the ecosystem.
00:03	<TabAtkins>	WH: I'm really reluctant about this. It creates a rift in the ecosystem with two different ways of doing the same thing, which means that half of the people will adopt one way and half will adopt the other way. There will be friction at the boundaries. So far, I see this as just a different function calling syntax, but with a separate namespace.
00:04	<jschoi>	Yes, those comments. Part of them is about the separate namespace (which Hax is willing to drop and which bind-this does not have) but part of it is also about encouraging libraries disembodied `this`-based functions, which bind-this does share.
00:05	<jschoi>	I have argued that bind-this would not encourage that library style that much: its purpose is to make more convenient a very common and clunky method (.call and to a lesser extent .bind), but perhaps there is still risk.
00:05	<TabAtkins>	The namespace per se isn't necessary to Waldemar's complaint, it's the calling convention that bothers him.
00:06	<TabAtkins>	I have argued that bind-this would not encourage that library style that much: its purpose is to make more convenient a very common and clunky method (.call and to a lesser extent .bind), but perhaps there is still risk. I mean, Justin's comments in this very room imply that there will be demand for authoring in that library style ^_^
00:07	<TabAtkins>	And the fact that `foo::bar(baz)` is slightly shorter than `foo\|>bar(##, baz)` inclines me to believe him that it'll be at least somewhat common.
00:11	<jschoi>	I could have sworn, Tab, that, when I had raised this a few months ago in this room, you were less concerned about this ecosystem risk—but I could be remembering wrongly, haha. I would try searching the logs, but Bakkot’s fancy log search is giving me an error. 🥲
00:14	<jschoi>	…Anyways, regardless of whether people should publish libraries based on disembodied `this`-based functions or not, people are already using them with `.call` internally a lot for various reasons (such as conditionally switching between two methods or using `this` as a context object). My argument has been that we should discourage people publishing public libraries based on this style, but it’s already happening in internal APIs, and it is very common. It’s not just Array.prototype or Object.prototype methods in the dataset.
00:16	<jschoi>	That is: although this style should not be in public APIs, it is already happening and it is very frequent in private codebases (see the Gzemnid dataset), and it is yet another reason why .call’s brevity/clunkiness should be optimized with syntax.
00:19	<jschoi>	Call-on would solve it too, and I am fine with that as a compromise, but I don’t think bind-this would bring significant ecosystem schism either.
00:19	<jschoi>	And I also think bind-this’s redundancy with the pipe operator is small (just like how Function.pipe’s redundancy with the pipe operator is small). I’m not too concerned when the same problem is addressed by two proposals…I am more concerned where the same problem is addressed by three proposals (such as where pipe operator, bind-this, and PFA syntax all overlap in my diagram).
00:21	<TabAtkins>	Private codebases can do whatever bizarre stuff they want; I've written my share of heavily-functional private JS, after all. It's still virtually unheard of to actually publish a library expecting its functions to be called with `.call()`.
00:23	<jschoi>	Yes, that is true. `.call` is very common, even excluding Array.prototype and Object.prototype methods (e.g., for conditionally switching between methods), but there is no known public API that is based on disembodied `this`-based functions that would depend on `.call`. And it should probably stay that way.
00:26	<jschoi>	Actually, I take it back: I think there are some public APIs that involve the user supplying a custom `this` value in the dataset. Whether this should be encouraged is another question…but, anyways, there are many extant use cases of `.call` in the dataset, which sum up to a big number.
00:26	<TabAtkins>	Thus me being happy to address it. ^_^
00:27	<jschoi>	Haha, yes. Anyways, I think the TIMTOWDI issue is the bigger fundamental question.
00:28	<jschoi>	Some TIMTOWDI is unavoidable, and total TOOWTDI is impossible, no matter how much you want to reach Python zen, but how much TIMTOWDI is acceptable…? We will need to ask plenary, because the question bumps against TC39’s fundamental approach to its proposals and how it judges them on their own merits.
00:28	<TabAtkins>	yup
00:29	<TabAtkins>	also i'm shifting call-this to `@()` because after some thought I think it looks really good
00:30	<jschoi>	`slice@(arrLike, 1)`. “Slice at this `arrLike`.”
00:30	<jschoi>	`arrLike \|> slice@(#, 1)`. “The `arrLike`, slice at it.”
00:34	<jschoi>	`arrLike::slice(1)`. “`arrLike`’s slice.” To me, these are all fine and better than the `.call`-based status quo…
00:37	<jschoi>	(I think the ecosystem-schism concern applies to `slice@(arrLike, 1)` as much as it does to `arrLike::slice(1)`. And I don’t think the ecosystem-schism risk is very large for either proposal. The big issue is TIMTOWDI vs. avoiding proposal redundancy.)
00:41	<TabAtkins>	I strongly disagree that that `slice@(r, 1)` promotes ecosystem schisming. Writing a library in this fashion means your user's code is identical to if you'd just written a normal function, except slightly longer. There's literally no benefit.
00:42	<jschoi>	What I mean is that it might encourage publishing a library that exports a `slice` function that relies on `this`, and which therefore relies on `.call` or `@()`.
00:42	<jschoi>	I myself do not think this risk is very large, but it may be similar to that encouraged by bind-this.
00:43	<TabAtkins>	Right, I'm saying it doesnt' encourage that, because there is literally no benefit to doing so, only a (very small) downside.
00:43	<jschoi>	Oh, you mean because it has no improvement in word order / fluency…without the pipe operator.
00:43	<TabAtkins>	Versus bind-this, which actually does have an upside to doing so - `foo::bar()` is shorter than `foo \|> bar(#)`
00:44	<jschoi>	Ah, the slight improvement in conciseness too, yes. I understand now.
00:49	<jschoi>	So, “`.call` is very frequent, and therefore its conciseness deserves to be improved, but we want to avoid ecosystem schism, so we don’t want to improve it too much”?
00:52	<TabAtkins>	That's my thesis, yeah
03:35	<ljharb>	i don’t see how it’d cause ecosystem schism
03:36	<ljharb>	It’d be used for all the places .call is already used. Why would anyone go out of their way to design a standalone function to accept a receiver? The feature is only for borrowing prototype methods.