mapTo + flatten might need lazy evaluation

[staltz]

There are cases where mapTo(innerStream) is simply not the same as map(() => innerStream) because the former does lazy evaluation of the innerStream expression, which may involve the creation of a new stream, eg if innerStream expression was source.compose(dropUntil(second)).

Here's an example:

 function notBetween(first, second) {
   return source => xs.merge(
     source.endWhen(first),
-    first.mapTo(source.compose(dropUntil(second))).flatten()
+    first.map(() => source.compose(dropUntil(second))).flatten()
   )
 }

The map works but not the mapTo.

This bug/behavior is not a top priority, but something we should be aware of, in case someone else trips over this.

It may also be related to the asynchronous stop when switching the inner stream in the flatten.

[TylorS]

I think that this is solved now since mapTo(x) is really just a call to map(() => x)

[staltz]

Not really, because x is eagerly evaluated in mapTo(x) but lazily evaluated in map(() => x). This issue is marked bug but I think it's rather unsolvable. What we could do is forbid passing a stream to mapTo, so we always pass streams in map, for lazy evaluation.

[TylorS]

But they are the same now, no? https://github.com/staltz/xstream/blob/master/src/core.ts#L1699

[staltz]

Not really, because

function multiply(x) {
  return x * Math.random();
}

is different to

const multiply = makeMultiplyFunction(Math.random());

given

function makeMultiplyFunction(c) {
  return function multiply(x) {
    return x * c;
  } 
}