Re: Function composition vs pipeline

I don’t know the implications but I could easily imagine the pipeline proposal being extended to not taking any input on the left hand side and effectively represent composition in the opposite direction. For example: ``` let h = |> f |> g h(2) //g(f(2)) ``` That said, the point holds for the

Re: Function composition vs pipeline

The function composition operator composes function pipelines into functions for later use and/or further composition. Those functions still need to be called via the existing `()` syntax, so it doesn't offer a different way of calling functions as such. The function pipeline operator calls the

Re: Promise finally

Yes, indeed, I should have said "is required to call `.then` *at least* twice." It's funny you should mention this nuance, because I recently opened a pull request against the `Promise.prototype.finally` proposal repository that would solve exactly this problem, as well as simplifying polyfills

Promise finally

In other words ```js Promise.resolve().finally(() => {}).then(() => { console.log(1); }); Promise.resolve().then(() => {}).then(() => { console.log(2); }).then(() => { console.log(3); }); ``` prints 2, then 3, then 1. ___ es-discuss mailing list

Promise finally

@Ben Newman There are 2 extra ticks, not just 1. The first one is caused by step 8 of 25.6.5.3.1 and the other one is caused by the fact that the `thenFinally` callback passed in step 7 of 25.6.5.3 returns a promise. I'm wondering if this trade-off is the right one.

Re: Promise finally

This ordering of `console.log` calls seems to happen because `Promise.prototype.finally` is specified in terms of `Promise.prototype.then`, and is required to call `.then` twice. Note the `Invoke(promise, "then", « thenFinally, catchFinally »)` here

Re: Promise finally

On 2/23/18 9:30 AM, Michael Luder-Rosefield wrote: Whenever you chain a promise with a then/finally, you're basically letting the runtime look at the callbacks at some arbitrary point in the future, no? Not if the promise is already known to be resolved. In that case, the exact behavior of

Re: Promise finally

Whenever you chain a promise with a then/finally, you're basically letting the runtime look at the callbacks at some arbitrary point in the future, no? So despite being written in a defined order, they will be run in whatever order eventuates. On Fri, 23 Feb 2018 at 14:24 Raul-Sebastian Mihăilă

Re: Promise finally

The order is deterministic, as specified, I just don't think it's the right order. I don't have a concrete example with finally, but if I were to imagine one, say you're writing some tests with jest and you want to make some checks in the then callbacks. In order for those checks to be executed in

Re: Re: Function composition vs pipeline

See also recent discussions in these GitHub issues that touch on composition: https://github.com/tc39/proposal-pipeline-operator/issues?q=composition+sort%3Aupdated-desc. Look particularly at the issues that were created after 2018-01-31 – when Gilbert/Mindeavor split the proposal into four

Re: Promise finally

Since these two Promises aren't chained to one another I wouldn't expect any specific deterministic ordering between the `console.log` statements. Are you suggesting that such a deterministic ordering should be imposed by using micro tasks or what are you proposing here exactly? In other words,

Promise finally

I find it weird that ```js Promise.resolve().finally(() => {}).then(() => { console.log(1); }); Promise.resolve().then(() => {}).then(() => { console.log(2); }); ``` prints 2 and then 1. It would have been possible to spec it in such a way that it would have printed 1 and 2. On the other hand