Official changes thread

[js-choi]

This is an official announcement thread for significant changes to the proposal’s explainer or spec. These will include things like:

• Switching to another token for the topic reference (see #91).
• Adding new big sections, such as FAQ sections, to the explainer.
• Changes in the proposal’s Stage or other related proposals’s Stages during TC39 plenaries.
• The results of other related official meetings, like TC39 incubator calls.

If you'd like to be informed only about significant changes, subscribe to this thread rather than the repository. :)

[js-choi]

I’ve temporarily switched the topic token back from ^ to # (see #250). As per https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-926357211, I think my change of the spec from % to ^ was premature, partially because I now mildly prefer % again, but mostly because it’s what we presented to plenary on August and because it’s what Babel currently supports (see babel/babel#13749).

This is a tentative change and has no bearing on what the actual final topic token will be. It’s just a swap to the explainer and spec back to what we presented to the Committee plenary on August.

This will be almost certainly be the last time I switch the topic token until we hold our TC39 incubator sessions for bikeshedding the token, in early November.

---

We’ve also added a new “Relationships” section (#241, closing #220) that talks about relationships to other proposals, like PFA syntax, eventual-send, and Function helpers. We also added a section “F# pipes have been rejected by TC39 multiple times”, partially addressing #221 and #202.

[js-choi]

Starting on 2021-10-25, another formal Commitee plenary occurred. The notes have now been published. We have summarized these updates in #256.

The pipe operator was not presented at this meeting, although an incubator meeting on 2021-11 is chartered for bikeshedding the pipe operator’s topic token. We will post an update about this soon.

Other notes regarding this plenary meeting:

• PFA (partial function application) syntax was presented again to the Committee plenary for Stage 2. The Committee rejected this proposal; several representatives, including those from Mozilla SpiderMonkey and Google V8, stated that there were insufficiently specific and compelling use cases presented, with high syntax cost and novelty in comparison to arrow functions.

• A proposal for several Function helpers including Function.pipe and flow was also presented to the Committee plenary for Stage 1. The Committee also rejected this proposal due to its being overly broad, and it requests that it be split up into multiple proposals. There is now a new Stage-0 proposal devoted to Function.pipe and flow.

[js-choi]

We had a recent formal TC39 incubator call with publicly available notes in late November 2021.

• We decided for now to switch to two-character topic tokens (^^, @@, or %%). A summary has been given in https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-990614661. (# might still be in the running but is blocked by tc39/proposal-record-tuple#10.)
• We decided to keep optional pipes (#198) as a separate future proposal.
• We discussed concerns from the Committee about redundancy with several other proposals that could also be used for “chaining dataflow” (such as bind-this, extensions, and PFA syntax). We don’t plan to advance this proposal to Stage 3 until all proposals we holistically consider all such “dataflow” proposals in future meetings.

[js-choi]

Since December, TC39 has continued to discuss the pipe operator in the greater context of “dataflow”. Because this discussion is so crucial to the prospects of the pipe operator (as well as related proposals such as Function.pipe()), here is a summary of what has happened since December. I have also added this to HISTORY.md.

2021-12: Holistic-dataflow articles

The “dataflow” proposals include the following:

• The pipe operator … |> … (aka “Hack pipes”)
• Function.pipe (a function version of the F# pipe operator)
• The bind-this operator …::… (and its variant call-this …@(…))
• The Extensions syntaxes …::…, …::…:…, and const ::{ … } = …;
• Partial function application …~(…) (aka “PFA syntax”)

There are several “dataflow” proposals that overlap in various complicated ways. Multiple TC39 representatives have expressed concerns about redundancies between these proposals—that the space as a whole needs to be holistically considered, that goals need to be more specifically articulated, and that there is not enough “syntax budget” in the language to approve all of these proposals. This applies to the pipe operator, as well as all the others in that list.

• In late December, I wrote an article detailing how these proposals overlap. (I am one of the TC39 co-champions of this pipe proposal, as well as Function.pipe and the bind-this operator.)
• @tabatkins then wrote a response article on their own blog. (@tabatkins is another TC39 co-champion of the pipe operator.)
• Later, @hax would also write another response article. (@hax is a TC39 champion of the Extensions syntaxes.)

2022-01: Plenary meeting

On January 26, 2022, a plenary meeting was held to discuss these overlapping proposals holistically. This discussion overflowed into an ad-hoc meeting on the next day.

In these two meetings, TC39 representatives debated over such topics as:

• Creating a unified language versus accommodating multiple programming paradigms (e.g., object oriented versus functional).
• TMTOWTDI versus TOOWTDI.
• Whether generalized language features (like the Hack-style pipe operator) or specialized features (like Function.pipe, the F#-style pipe operator, and the bind-this operator) were more desirable.
• Whether it is better for language features to be universal or prescriptive in their usage.
• The merits of specific dataflow proposals, including the pipe operator.

Support among TC39 representatives for the pipe operator as it is now (with a Hack-style topic reference) appears to range from strongly in favor to weakly against. Several representatives reaffirmed that they are moderately or strongly against F#-style syntax. Support for Function.pipe appears to be tepid: neither strongly positive or negative. For more details, see the conclusions of the ad-hoc overflow meeting.

2022-03: Upcoming

There is an upcoming plenary meeting. We are planning to continue the holistic dataflow discussion. We are also planning to further bikeshed the topic reference’s token, hoping that we will resolving on a final decision. See the 2021-03 slides. We are not planning to advance the pipe operator to Stage 3 at this meeting, but, if we are able to settle on a final topic token, then we may attempt to advance it at the subsequent meeting in May.

[js-choi]

At the 2022-03 plenary meeting, the Committee mildly preferred @ as the topic reference.

A pull request for changing the specification to use @ has been made: #268.

In related news, an update about call-this was also presented (see https://github.com/tc39/proposal-call-this/issues/10#issuecomment-1078600416), and the Committee mildly preferred receiver-first tight binding. However, call-this continues to polarize the Committee due to ecosystem-schism concerns. (Note: There is a representative who will not allow the pipe operator to advance unless call-this also advances. That is why the pipe proposal is so tightly coupled to the call-this proposal.)

[js-choi]

2022-04

Due to concerns raised by a TC39 delegate (https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-1084946624), @ has been excluded as a topic reference. We’re looking again at ^^, @@, %%, #_, etc.

2022-07

Starting at https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-1182576121, we’ve been taking a fresh look at identifier-like contextual keywords like $_, with the caveat that such a contextual keyword must not be an already-commonly-used identifier and that it would be a syntactic and static binding rather than a runtime ordinary variable.

In the plenary on July 21, proposal-function-pipe-flow was formally presented to the Committee, and it was rejected for Stage 1. The Committee generally found its use cases either easily solved by userland functions, such as:

function pipe (input, ...fnArray) {
  return fnArray.reduce((value, fn) => fn(value), input);
}

…or also solved by the pipe operator (this proposal). (Eventually, after the pipe operator gains users, pain points with the pipe operator may be enough motivation to revive proposal-function-pipe-flow, but that would not occur for a long time.)

There is another incubator call chartered for more pipe-operator bikeshedding, which might or might not occur before the September plenary.