Flow: Support Pipeline Operator

[k15a]

The pipeline |> operator is a proposal which is currently in stage 1. It would be great if flow could support this proposal.

I could imagine that this is not too hard because it's basically only syntactic sugar for function calls IIRC.

https://github.com/tc39/proposal-pipeline-operator

[Hypnosphi]

I would like to help implementing that. Where should I start?

[gajus]

It has landed in Firefox under --enable-pipeline-operator compile flag.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Pipeline_operator

[mAAdhaTTah]

I've commented this elsewhere, but I strongly suggest avoiding implementing the pipeline operator until we've at least selected which of the 3 proposals we're going with. It's been in Firefox for some time behind a flag, but my current understanding is the FF implement doesn't currently conform with any of the 3 proposals' current semantics.

[sartaj]

@mAAdhaTTah It seems Proposal 0 fits specs for all other proposals. Couldn't flow at least implement this minimal behavior to start? This would benefit anyone who would love to use piped unary functions with typed data structures.

[mAAdhaTTah]

Don't assume that will remain the case. We're exploring some ideas to drop parens around arrow functions in F# Pipelines. These proposals are stage 1 because they're still very much in flux.

[Hypnosphi]

Flow is still 0.x so I personally wouldn't mind if this would be supported in some form now and then changed later

[johnsonw]

I would really like to see this move forward. After spending quite some time in F# I find myself using the pipeline operator routinely. https://babeljs.io/docs/en/babel-plugin-proposal-pipeline-operator shows that we can use the "minimal" proposal at the moment. Is there any way to suppress the following error:

 21:   const c = xs |> fn1 |> fn2 |> fn3;
                            ^ Unexpected token >

// $FlowFixMe doesn't seem to ignore the error.

[pnevyk]

// $FlowFixMe doesn't seem to ignore the error.

That's because $FlowFixMe is for suppressing type errors. However, this is "syntax error" for flow parser so it does not get into the type checking phase at all.

[bsmith-cycorp]

Please please please fix this. The "minimal" spec (1-arity functions) seems very unlikely to change and relatively easy to parse, and it's pretty much all that people are asking for.

[mAAdhaTTah]

The "minimal" spec (1-arity functions) seems very unlikely to change

Do not assume this. There are 3 proposals, and the "minimal" spec is unlikely to be accepted as-is.

[Hypnosphi]

the "minimal" spec is unlikely to be accepted as-is

Its benefit is not that it's the one that will be accepted most likely, but the fact that other proposals are supersets of the minimal one. So if you support the minimal proposal now, there will be no breaking changes required to support whichever of the advanced proposal wins later

[mAAdhaTTah]

the fact that other proposals are supersets of the minimal one.

They are not. This is valid in minimal:

x |> f(y)

but not currently valid in smart (requires a placeholder token).

[gajus]

It would be nice to support this that Babel added support:

• https://github.com/babel/babel/blob/master/CHANGELOG.md#v750-2019-07-04
• https://babeljs.io/docs/en/babel-plugin-proposal-pipeline-operator

[goodmind]

@gajus which one? F# or smart?

[gajus]

F# Pipelines

Based on the conversations I have been seeing, it is extremely unlikely that smart is going to be implemented. F# Pipelines is the way forward.

[goodmind]

Can't find what stage it is on

[noppa]

There are _three_ different proposals being considered, the two mentioned in the proposal readme and Elixir-style pipelines. It would be pretty amazing if Flow could support all three with a configuration option to select which one (if any) to use in a project. That way people could experiment with the different proposals and give feedback on them. Although of course adding support for all three is a lot more work than for just one.

[goodmind]

@mAAdhaTTah can you confirm that smart pipelines is unlikely to be implemented?

[goodmind]

@noppa

s/two/three

[goodmind]

I might give a try at implementing F# pipeline operator parsing in Flow (without typechecking)

[mAAdhaTTah]

No, I can not confirm that. Until a final decision is made, all options are on the table.

[chicoxyzzy]

The final decision on which proposal to choose most likely won't be made until at least October TC39 meeting or even later

[goodmind]

@noppa I can't find Elixir proposal itself, only mentions about it

[noppa]

@goodmind I don't think there's anything more at the moment than the issue tc39/proposal-pipeline-operator#143, with some pretty good arguments for it (comment) and against (comment, comment).

I don't think there's actually a Babel plugin for it yet and I'm not sure if the specifics of it are defined well enough to actually implement yet... Sorry if I misled you by calling it a _proposal_ when at the moment it seems to be more like a _suggestion_.

If you are doing the F#-style proposal, btw, there's _also_ partial application, which is a separate proposal but would go well with the F# style pipelines.

[mAAdhaTTah]

Yeah, there currently aren't any active plans to implement Elixir-style pipelines in Babel, nor are there specs for it, although Daniel (the proposal champion) has been pushing a "try everything" philosophy, so we may end up doing it.

[goodmind]

@gajus Well, I guess if you want to try F# pipelines with Flow you can build my branch