the most important feature of Hack pipes is that, like other pipe styles and like call-this, it encourages DCE-friendly API use.

👏👏👏👏

I really strongly believe we need to stay focused on this particular point. It benefits basically all of humanity, and the poorest the most.

FWIW, I don't think this is a great argument since all call-this spellings face similar "I got them mixed up" objections. E.g. other delegates have said things like: "I never want a beginner to wonder 'which was it again? . or ~>?'" So I have been going forward with the assumption that some people are going to get mixed up sometimes and the important goal is "easy to detect a mistake" and "easy to fix a mistake" not "hard to make a mistake".

1. Syntax constraints / autocomplete / linters / TS / asserts / tests all help prevent actual bugs sneaking in;
2. starting with a . makes it easy to discover both member methods and tree-shakable methods; I never have to wonder where to start since it's the same character either way
3. if you mistype it, it's the easiest to recover from. One keypress to flip to the other option.
4. I was hoping using another character familiar to method-chainers . would make the switch feel "simple" or at least "not as scary". To invoke a method, use .; to invoke an extension method, use .. (extend the dot). Easy.
5. IMO any of ::, .., ~>, etc will be fine to learn for people who find themselves stuck with what we decide. They will just learn it and move on... or the AI will write the code for them and it won't matter anyways. We are never going to come up with something immediately intuitive to everyone...

Another aspect of this discussion that I think merits consideration, given a goal of persuading method users to switch to something more tree-shakable: precedence. Methods are tight, which means there are several cases where migrating from normal method calls to a "loose" pipeline is... awkward. As a simple example, take any awaited method call:

// Class methods
await this.deletePost(id);

// Call-this / tight-elixir
await this..deletePost(id); // Easy peasy

// Hack
await this |> deletePost(##, id); // Oops!
this |> await deletePost(##, id); // No more bug, but this is pretty different from method chaining at this point...
await (this |> deletePost(##, id)); // No more bug, but oof, we're back to paren-balancing...

Has this issue been discussed yet?

Another example is arithmetic between the results of two method calls, based on real example for our codebase:

// Class methods
this.fn1() + this.fn2(arg1, arg2);

// Call-this / tight-elixir
this..fn1() + this..fn2(arg1, arg2);

// Hack
(this |> fn1(##)) + (this |> fn2(##, arg1, arg2));

// Plain functions
fn1(this) + fn2(this, arg1, arg2);

Boolean expression, also based on a real example:

// Class methods
if (foo && !bar.isBar()) { ... }

// Call-this / tight-elixir
if (foo && !bar..isBar()) { ... }

// Hack
if (foo && !(bar |> isBar(##))) { ... }

// Plain functions
if (foo && !isBar(bar)) { ... }

Evan Winslow:

Can I persuade anyone to update the call-this and pipeline repos to explicitly mention DCE as THE primary motivation, and others as secondary motivations?

I would be glad to take pull requests for both the pipe and call-this proposals. TabAtkins, rbuckton, and I are currently the co-champions of the pipe proposal, and I am the champion of the call-this proposal.
I have also been putting off a rewrite of the pipe README for years because of work. Once I have some personal bandwidth, I will try to prioritize revisions that give this more emphasis over the next few weeks.

One caution about emphasizing DCE’s benefits for call-this: if both pipe and call-this are framed primarily around DCE, that increases the chance that some people in TC39 (e.g., browser implementers, Mark Miller) will press us to pick just one of them as the DCE-friendly dataflow feature. And there are also people in TC39 (e.g., ljharb) who would prefer call-this over pipe if it came down to choosing only one.

[from September 2017] @littledan makes a first presentation for F#-or-Elixir pipes to TC39, successfully advancing to Stage 1. However, parts of TC39 object to redundancy with a bind operator. A condition of the advancement to Stage 1 is that it would not be redundant with a bind operator; this will become relevant later.

[from August 2018] ljharb voices concern that advancing pipe would kill any future bind operator (see § 2017-09). Other representatives respond that Hack pipes are now orthogonal to any bind operator and would not kill it. @ljharb decides not to block Stage 2.

I would be unhappy if we ended up with pipe operator but not call-this, but I would be even more unhappy with call-this and no pipe operator. I want to be able to use existing standalone functions: current DCE-friendly modules that do not use this—which is almost all of them—as well as built-ins like Object.entries and Array.from. There are very few APIs, if any, built around standalone this-based methods, aside from Node’s internal primordials, and I am not even sure whether Node still relies on those.

That is one reason I have tried to emphasize call-this use cases that are not really about dataflow. The existing call-this README purposefully spends a lot of time on method wrapping, conditional method switching, method reuse after monkey patching, prototype-pollution protection, and other reasons why people use .call today. Currently, it purposefully does not mention dataflow at all. The idea is to argue that .call is common enough to deserve syntax on its own, regardless of whether it is being used for DCE-friendly dataflow, to avoid it overlapping with the pipe operator. (I have also explored a demethodize function method, equivalent to Function.call.bind, that would make those cases more ergonomic too, but ljharb has said it would not address his own use cases unless it were syntax.)

I would be unhappy if we ended up with pipe operator but not call-this, but I would be even more unhappy with call-this and no pipe operator.

You must be as miserable as me right now, having neither ^_^

I would not ask, because they already decided it was worth making some people mad to get tree-shaking, so they are not the audience for my efforts here. New syntax will not improve their tree-shakability.

Their users might ask I suppose. And if they decided to oblige and provide a call-this-compatible API, that would simply be their prerogative as library maintainers. Same as picking any other style like class methods, first-arg, last-arg, curried...

The argument here is that having a fluent style for ordinary functions might make users more likely to choose APIs that use ordinary functions

To be clear, I agree with this argument. I just maybe have different intuitions about the magnitude of the effect?