Inconsistent argument order in takeuntil

[zspecza]

Given this excerpt from the readme, I assume all flyd modules should accept the operation data as the last parameter:

More functional in style. Flyd is more functional than existing FRP libraries. Instead of methods it gives you curried functions with arguments in the order suitable for partial application. This gives more expressive power and modularity.

Why does takeuntil deviate from this paradigm? Is there a specific reason?

To me, takeuntil(endStream, source) makes more sense.

I can make a pass at a PR for this, just want to find out if it's not an important design decision that I'm missing the point of first.

[irisjae]

This bit me today. Should I make a PR?

[irisjae]

In fact, as a side note, I found many of the modules listed to be the causes of problems which disappeared once I replaced them with flyd.transduce and Ramda. Perhaps, either they should be much more scrutinized, or just drops those which have Ramda equivalents.

[nordfjord]

I agree, this is very surprising behaviour.

I think we need to either

1. Flip the argument order
2. Document why this is the argument order in the readme for takeuntil

Personally I always import takeuntil like this

import * as takeuntil from 'flyd/module/takeuntil';
const takeUntil = R.flip(takeuntil);