5 ms·

We might be able to cross one more language off your wishlist soon, Javascript is on the way to getting a pipeline operator, the proposal is currently at Stage

We might be able to cross one more language off your wishlist soon, Javascript is on the way to getting a pipeline operator, the proposal is currently at Stage 2 https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator I'm very excited for it.

zdragnar 1y ago
I worry about "soon" here. I've been excited for this proposal for years now (8 maybe? I forget), and I'm not sure it'll ever actually get traction at this point.
hoppp 1y ago
Cool I love it, but another thing we will need polyfills for...
- bobbylarrybobby 1y ago
  How do you polyfill syntax?
  - jononor 1y ago
    Letting your JS/TS compiler convert it into supported form. Not really a polyfill, but it allows to use new features in the source and still support older targets. This was done a lot when ES6 was new, I remember.
    - zdragnar 1y ago
      Polyfills are for runtime behavior that can't be replicated with a simple syntax transformation, such as adding new functions to built-in objects like string.prototype contains or the Symbol constructor and prototype or custom elements. I haven't looked at the member properties bits but I suspect the pipeline syntax just needs the transform to be supported in build tools, rather than adding yet another polyfill.
- hathawsh 1y ago
  I believe you meant to say we will need a transpiler, not polyfill. Of course, a lot of us are already using transpilers, so that's nothing new.
TehShrike 1y ago
I was excited for that proposal, but it veered off course some years ago – some TC39 members have stuck to the position that without member property support or async/await support, they will not let the feature move forward. It seems like most people are just asking for the simple function piping everyone expects from the |> syntax, but that doesn't look likely to happen.
- packetlost 1y ago
  I don't actually see why `|> await foo(bar)` wouldn't be acceptable if you must support futures. I'm not a JS dev so idk what member property support is.
  - cogman10 1y ago
    Seems like it'd force the rest of the pipeline to be peppered with `await` which might not be desirable "bar" |> await getFuture(%); |> baz(await %); |> bat(await %); My guess is the TC committee would want this to be more seamless. This also gets weird because if the `|>` is a special function that sends in a magic `%` parameter, it'd have to be context sensitive to whether or not an `async` thing happens within the bounds. Whether or not it does will determine if the subsequent pipes are dealing with a future of % or just % directly.
    - packetlost 1y ago
      It wouldn't though? The first await would... await the value out of the future. You still do the syntactic transformation with the magic parameter. In your example you're awaiting the future returned by getFuture twice and improperly awaiting the output of baz (which isn't async in the example). In reality it would look like: "bar" |> await getFuture() |> baz() |> await bat() (assuming getFuture and bat are both async). You do need |> to be aware of the case where the await keyword is present, but that's about it. The above would effectively transform to: await bat(baz(await getFuture("bar"))); I don't see the problem with this.
      - 1y ago
chilmers 1y ago
It also has barely seen any activity in years. It is going nowhere. The TC39 committee is utterly dysfunctional and anti-progress, and will not let any this or any other new syntax into JavaScript. Records and tuples has just been killed, despite being cited in surveys as a major missing feature[1]. Pattern matching is stuck in stage 1 and hasn't been presented since 2022. Ditto for type annotations and a million other things. Our only hope is if TypeScript finally gives up on the broken TC39 process and starts to implement its own syntax enhancements again. [1] https://2024.stateofjs.com/en-US/usage/#top_currently_missing_from_js https://2024.stateofjs.com/en-US/usage/#top_currently_missin...
- johnny22 1y ago
  Records and Tuples weren't stopped because of tc39, but rather the engine developers. Read the notes.
  - davidmurdoch 1y ago
    Aren't the engine devs all part of the TC39 committee? I know they stopped SIMD in JS because they were mire interested in shipping WASM, and then adding SIMD to it.
    - johnny22 1y ago
      I would say representatives of the engine teams are involved. However not involved enough clearly, because it should have been withdrawn waaay before now due to this issue.
  - Osiris 1y ago
    It was also replaced with the Composite proposal, which is similar but not exactly the same.
- tkcranny 1y ago
  I wouldn’t hold your breath for TypeScript introducing any new supra-JS features. In the old days they did a little bit, but now those features (namely enums) are considered harmful. More specifically, with the (also ironically gummed up in tc39) type syntax [1], and importantly node introducing the --strip-types option [2], TS is only ever going to look more and more like standards compliant JS. [1] https://tc39.es/proposal-type-annotations/ https://tc39.es/proposal-type-annotations/ [2] https://nodejs.org/en/blog/release/v22.6.0 https://nodejs.org/en/blog/release/v22.6.0
hinkley 1y ago
All of their examples are wordier than just function chaining and I worry they’ve lost the plot somewhere. They list this as a con of F# (also Elixir) pipes: value |> x=> x.foo() The insistence on an arrow function is pure hallucination value |> x.foo() Should be perfectly achievable as it is in these other languages. What’s more, doing so removes all of the handwringing about await. And I’m frankly at a loss why you would want to put yield in the middle of one of these chains instead of after.
rossriley 1y ago
PHP RFC for version 8.5 too: https://wiki.php.net/rfc/pipe-operator-v3 https://wiki.php.net/rfc/pipe-operator-v3
gregabbott 1y ago
A while ago, I wondered how close you could get to a pipeline operator using existing JavaScript features. In case anyone might like to have a look, I wrote a proof-of-concept function called "Chute" [1]. It chains function and method calls in a dot-notation style like the basic example below. chute(7) // setup a chute and give it a seed value .toString // call methods of the current data (parens optional) .parseInt // send the current data through global native Fns .do(x=>[x]) // through a chain of one or more local / inline Fns .JSON.stringify // through nested global functions (native / custom) .JSON.parse .do(x=>x[0]) .log // through built in Chute methods .add_one // global custom Fns (e.g. const add_one=x=>x+1) () // end a chute with '()' and get the result [1] https://chute.pages.dev/ https://chute.pages.dev/ | https://github.com/gregabbott/chute https://github.com/gregabbott/chute

zdragnar 1y ago

I worry about "soon" here. I've been excited for this proposal for years now (8 maybe? I forget), and I'm not sure it'll ever actually get traction at this point.

hoppp 1y ago

Cool I love it, but another thing we will need polyfills for...

bobbylarrybobby 1y ago
How do you polyfill syntax?
- jononor 1y ago
  Letting your JS/TS compiler convert it into supported form. Not really a polyfill, but it allows to use new features in the source and still support older targets. This was done a lot when ES6 was new, I remember.
  - zdragnar 1y ago
    Polyfills are for runtime behavior that can't be replicated with a simple syntax transformation, such as adding new functions to built-in objects like string.prototype contains or the Symbol constructor and prototype or custom elements. I haven't looked at the member properties bits but I suspect the pipeline syntax just needs the transform to be supported in build tools, rather than adding yet another polyfill.
hathawsh 1y ago
I believe you meant to say we will need a transpiler, not polyfill. Of course, a lot of us are already using transpilers, so that's nothing new.

TehShrike 1y ago

I was excited for that proposal, but it veered off course some years ago – some TC39 members have stuck to the position that without member property support or async/await support, they will not let the feature move forward. It seems like most people are just asking for the simple function piping everyone expects from the |> syntax, but that doesn't look likely to happen.

packetlost 1y ago
I don't actually see why `|> await foo(bar)` wouldn't be acceptable if you must support futures. I'm not a JS dev so idk what member property support is.
- cogman10 1y ago
  Seems like it'd force the rest of the pipeline to be peppered with `await` which might not be desirable "bar" |> await getFuture(%); |> baz(await %); |> bat(await %); My guess is the TC committee would want this to be more seamless. This also gets weird because if the `|>` is a special function that sends in a magic `%` parameter, it'd have to be context sensitive to whether or not an `async` thing happens within the bounds. Whether or not it does will determine if the subsequent pipes are dealing with a future of % or just % directly.
  - packetlost 1y ago
    It wouldn't though? The first await would... await the value out of the future. You still do the syntactic transformation with the magic parameter. In your example you're awaiting the future returned by getFuture twice and improperly awaiting the output of baz (which isn't async in the example). In reality it would look like: "bar" |> await getFuture() |> baz() |> await bat() (assuming getFuture and bat are both async). You do need |> to be aware of the case where the await keyword is present, but that's about it. The above would effectively transform to: await bat(baz(await getFuture("bar"))); I don't see the problem with this.
    - 1y ago

chilmers 1y ago

It also has barely seen any activity in years. It is going nowhere. The TC39 committee is utterly dysfunctional and anti-progress, and will not let any this or any other new syntax into JavaScript. Records and tuples has just been killed, despite being cited in surveys as a major missing feature[1]. Pattern matching is stuck in stage 1 and hasn't been presented since 2022. Ditto for type annotations and a million other things. Our only hope is if TypeScript finally gives up on the broken TC39 process and starts to implement its own syntax enhancements again. [1] https://2024.stateofjs.com/en-US/usage/#top_currently_missing_from_js https://2024.stateofjs.com/en-US/usage/#top_currently_missin...

johnny22 1y ago
Records and Tuples weren't stopped because of tc39, but rather the engine developers. Read the notes.
- davidmurdoch 1y ago
  Aren't the engine devs all part of the TC39 committee? I know they stopped SIMD in JS because they were mire interested in shipping WASM, and then adding SIMD to it.
  - johnny22 1y ago
    I would say representatives of the engine teams are involved. However not involved enough clearly, because it should have been withdrawn waaay before now due to this issue.
- Osiris 1y ago
  It was also replaced with the Composite proposal, which is similar but not exactly the same.
tkcranny 1y ago
I wouldn’t hold your breath for TypeScript introducing any new supra-JS features. In the old days they did a little bit, but now those features (namely enums) are considered harmful. More specifically, with the (also ironically gummed up in tc39) type syntax [1], and importantly node introducing the --strip-types option [2], TS is only ever going to look more and more like standards compliant JS. [1] https://tc39.es/proposal-type-annotations/ https://tc39.es/proposal-type-annotations/ [2] https://nodejs.org/en/blog/release/v22.6.0 https://nodejs.org/en/blog/release/v22.6.0

hinkley 1y ago

All of their examples are wordier than just function chaining and I worry they’ve lost the plot somewhere. They list this as a con of F# (also Elixir) pipes: value |> x=> x.foo() The insistence on an arrow function is pure hallucination value |> x.foo() Should be perfectly achievable as it is in these other languages. What’s more, doing so removes all of the handwringing about await. And I’m frankly at a loss why you would want to put yield in the middle of one of these chains instead of after.

rossriley 1y ago

PHP RFC for version 8.5 too: https://wiki.php.net/rfc/pipe-operator-v3 https://wiki.php.net/rfc/pipe-operator-v3

gregabbott 1y ago

A while ago, I wondered how close you could get to a pipeline operator using existing JavaScript features. In case anyone might like to have a look, I wrote a proof-of-concept function called "Chute" [1]. It chains function and method calls in a dot-notation style like the basic example below. chute(7) // setup a chute and give it a seed value .toString // call methods of the current data (parens optional) .parseInt // send the current data through global native Fns .do(x=>[x]) // through a chain of one or more local / inline Fns .JSON.stringify // through nested global functions (native / custom) .JSON.parse .do(x=>x[0]) .log // through built in Chute methods .add_one // global custom Fns (e.g. const add_one=x=>x+1) () // end a chute with '()' and get the result [1] https://chute.pages.dev/ https://chute.pages.dev/ | https://github.com/gregabbott/chute https://github.com/gregabbott/chute