[TehShrike]

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]

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]

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.