Official changes thread

[js-choi]

To read a detailed history of this proposal, please see HISTORY.md.

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 Bikeshedding the Hack topic token #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 #91 (comment), 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 Bikeshedding the Hack topic token #91 (comment). (# might still be in the running but is blocked by Collect developer feedback about the ergonomics of #{ }/#[ ] (vs alternatives @[ ]/@{ } or {| }/[| ]) proposal-record-tuple#10.)
• We decided to keep optional pipes (Optional Hackpipes proposal #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 tc39/proposal-call-this#10 (comment)), 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 (#91 (comment)), @ has been excluded as a topic reference. We’re looking again at ^^, @@, %%, #_, etc.

2022-07

Starting at #91 (comment), 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.

[js-choi]

It’s 2025. It’s been nearly three years since the last update in mid-2022. What’s been going on with the JavaScript pipe operator?

• Many other people in the Committee remain strongly against encouraging tacit / point-free programming in JavaScript.
  • The strongest opposition to encouraging widespread tacit / point-free programming comes from the engine implementors themselves.
  • An update to Prior difficulty persuading TC39 about F# pipes and PFA #221 has more information about this.
  • Because of this, F#/Elixir-style pipes still do not have a chance to succeed, partial function application remains in stasis, and Function.pipe / flow (unary function composition) received much skepticism and has been withdrawn.
  • Hack-style / topic-style pipes (the current state of this proposal) remain the only viable path forward for standardized piping.
• The Committee in the past years has (understandably) become very stringent about any new syntax.
  • Complexity isn’t the problem. The pipe operator is widely known as the simplest syntactic proposal in all of TC39.
    • All new syntax is under the increased stringency of the Committee.
    • The pipe operator’s simplicity is even a disadvantage in the opinion of some people at TC39! Because it brings no new program capabilities that cannot already be done in userspace.
  • The pipe operator has become a prime target for the proposed new “JSSugar” layer, implemented exclusively by tooling rather than browsers.
    • This “JSSugar” idea is still very unsettled and unresolved.
    • But it is an example of how complicated introducing new syntax has become.
  • For this reason, the pipe champions have mostly been focusing their free time on “lower-hanging fruit” proposals in TC39 or other standards venues—proposals that don’t involve new syntax.
• A lot of the Committee discussion about pipe over the past years has also been bogged down in determining the right token for the topic reference (Bikeshedding the Hack topic token #91).
  • This has been especially troublesome in relation to other proposals such as tuples/records (which have now become composites; see 2025 February TC39 presentation update proposal-record-tuple#393).
  • It’s okay for us to wait and watch how other proposals in the same syntax space develop.
  • In particular, if composites no longer use # for their literal syntax, then pipe topics could use them. That would be a big deal. See Syntax for composite literals: bikeshedding proposal-composites#7.
• Discussion has also still been bogged down in the relationship between the pipe operator and similar proposals such as the call-this operator (which also encountered headwinds and skepticism regarding its usefulness and its risks of ecosystem schism).
  • For this reason, I plan to propose a pared-down Function.prototype.demethodize (or .unThis or .thisAsArg) method that does the job of some parts of call-this, with a lower footprint on the engines and more synergy with the pipe operator.
• Some members also desire more evidence or studies on how a pipe operator would impact developer coding, especially opposed to assigning to temporary variables.
  • See Role of usability studies in the explainer #216.
  • I continue to argue that the explainer’s real-world examples (and, indeed, any real-world codebase) show clear tendencies by developers to create poorly readable deeply nested expressions, instead of reaching for temporary variables.
    • Nevertheless, more empiric evidence for pipe’s impact would be good.
  • In the recent 2025-03 plenary’s TG5 workshop, the pipe operator was raised as a potential proposal to study again to answer these questions.
  • We will be pursuing any new study on the pipe operator as free volunteer time allows.
  • The next task here is to review the results of the previous pipe-operator usability study led by @codehag, from back around 2019.
  • Volunteers from academia are welcome to help review the previous study, design, and/or conduct the next study; please comment in [Meta] TC39 Proposal Usability Studies tg5#29 or file a new issue in tc39/tg5.
• We apologize for how long this has taken so far, but this is the nature of volunteer standards work.
  • We want to get it right the first time, because we won’t be able to change it later.
  • We may pursue another update presentation later this year, particularly with the potential new availability of # for pipe topics.
  • Volunteers interested in leading another academic usability study are welcome in tc39/tg5.
  • The pipe operator also might be one of the first test cases of any new “JSSugar” system, which is a big complication.
  • All in all, the pipe operator is definitely not going to reach Stage 4 this year.
• We’ll give another update here when anything changes.