Justin Ridgewell: You’ve expressed before the desire for object-oriented programmers to use less prototype methods and more individually exported functions. This is a big reason why you have supported adding the pipe operator. It’s part of a bigger shift in the ecosystem, e.g., with Firebase’s new JS API.

However, if both the pipe operator and the “this” operator get added to the language…do you anticipate yourself or other programmers individually exporting this-based functions for use with the “this” operator – rather than non-this-based functions for use with the pipe operator?

import { a, c, e, f } from 'A'; 
import { e } from 'B'; 
a.b |> c(^^).d :> e() |> f(^^).g;

a.b |> c(^^).d :> e() |> f(^^).g :> i()

I do present foo(this: x).bar() as one of the options in https://docs.google.com/presentation/d/1-MLGCibETPX8NiIvNJ1xOxiMS-NB8GCbDGNcB5patiU/edit?usp=sharing.

For what it’s worth, x :> foo().bar() would be (x :> foo()).bar().

Wait, right now, the operator’s RHS still must be an identifier, a chain of identifiers, or a parenthesized expression—like decorator expressions.

Right now x :> foo().bar() groups as (x :> foo()).bar(). Because it’s basically a slightly looser version of ., which is very tight.

Are you saying you would expect it to group as x :> (foo().bar())?

the way you already do it with .call is the problem. We need a way where the receiver appears before the function, just like in OOP chaining. in-arg-list doesn’t solve that problem, it just adds one of the weirder things in TS. Arg lists are for args, only.

which sigil we use or what precedence it has isn’t important to me, and we can bikeshed that all we like.

ljharb: You have expressed before that you dislike bracketed receiver-first style, like x![foo]().bar(). Can you elaborate on this: Do you dislike it as much as you dislike function-first style or this-argument style?

People already do things like bracketed receiver-first style “fluently” anyway, like with x[Symbol.iterator]().next()…