17:46
<TabAtkins>
Sigh, everyone keeps talking past each other, assuming only their own use-cases exist. Justin Ridgewell has said several times, flat-out, that they'd like to use the bind-this operator to produce "fluent API" libraries that are slightly more ergonomic than what pipe can do.
17:46
<TabAtkins>
If you're talking instead just about the call-this operator, then yes, it won't cause schism, for the reasons I already gave.
18:59
<ljharb>
ah, i guess I’d missed that
23:09
<sarahghp>
I wonder if space was made to discuss the more general question bringing up the use cases people imagine explicitly might make it easier to think about the proposals more broadly.
23:10
<sarahghp>
Overall though, this diagram and write-up are so interesting. I do have to say I'm a big pipe op fan and somewhat dubious about the others. Writing free-this functions seems like a big risk in terms of ecosystem bifurcation.
23:10
<sarahghp>

Elaborating ways to use this seems to me possibly undesirable, dev experience–wise. Anecdotally, I know some slice of devs avoid it & it's often brought up as one of the difficult parts of teaching/using JS (even came across that recently in digging back into React and their motivations for moving to hooks).

I also personally, but maybe only me, worry about PFA quite a lot. It's such a fundamental shift to decouple argument order with the order in which they are provided and I'm not certain there are use cases that aren't achievable by other means / are so common that they are worth the syntax cost / inscrutability trade-off. Even the example of memoizing and expensive operations could be addressed with (expensiveOp) => (a, b) => { .. }

23:11
<sarahghp>
Also, I think the example in Tab's gist is slightly incorrect, right? fn~(arg0, ?, arg2, ?) becomes (a)=>fn(arg0, a, arg2, a) and fn~(arg0, ?1, arg2, ?2) would be (a,b)=>fn(arg0, a, arg2, b).
23:11
<sarahghp>
Anyways, this is suddenly a lot of thoughts. I should probably write a gist too, 😆