Rereading:

It's worth noting here that mathematical function notation sometimes uses a subscript for a similar purpose: e.g. logb(x). We bind b first, and indeed, could pass logb as a function instead of feeding it an x right away.

Eg, we break up long chains:

foo
  .bar()
  .then(() => {
  });

the this-prefixed argument is a bit easier to grok to me:

{}.hasProperty(this: noPrototypeObject)
 
// or, if you want to pipe it

noPrototypeObject
  |> {}.hasProperty(this: #)

That way you only need the |> pipeline, can call with a custom this without needing to pipe at all, and keep all arguments in the argument list.

Eg,

const hasProperty = uncurryThis({}.hasOwnProperty);

noPrototypeObject
  |> hasProperty(#)

I still like your f(this: blah) idea, although it seems to be getting resistance from some others because of dissimilarity with TypeScript function definitions’ parameter syntax.

(Did you ever mention why you think f(blah:) is not viable?)

That’s funny, because I suggested it because of its similarity

Yeah, heh. I am referring specifically to bakkot’s most recent comment in the delegates room.

function f(ref x, ref y) {
  x = 1;
  y = 2;
}

let x;
let y;
f(ref x, ref y); 

x; // 1
y; // 2

function f(ref x) {
  x = 1;
}

class C {
  #x;
  constructor() {
    // hand private field to `f`
    f(ref this.#x);
  }
}

I’m not sure what you mean; my apologies. F# pipes and PFA syntax are indeed separate proposals. But Hack pipes don’t require any other proposal, although they somewhat overlap with several proposals.

F# pipes were considered but rejected for advancement several years ago, and PFA syntax was considered and rejected several months ago. But we can try to present either of them again in the future, if/when Hack pipes advance further first. And in the meantime I also plan to present Function.pipe, which are basically lightweight F# pipes.

I think Jordan (ljharb) might have espoused the philosophy that all proposals should be judged primarily on their own merits. But Jordan would also agree, I know, that cross-cutting concerns between proposals should also always be considered. That’s why some representatives asked for this holistic analysis of a bunch of proposals.

But, like Tab says, the big thing for each proposal is judging whether the proposal brings enough benefit…even if another proposal doesn’t also advance (especially if the other proposal is at high risk of never advancing).