Less hops in operator lifting.

[andersio]

The PR proposes to overhaul how SignalProducer produces a new instance of Signal.

Summary

1. The public API of SignalProducer remains untouched.

2. startWithSignal(_:) is no longer responsible of creating the Signal.

3. SignalProducer.Builder replaces the "start handler" as the internal representation of SignalProducer.

   The builder is responsible of creating an instance of Signal on request. It also creates a customised post-creation side effect and an interrupt handle for every produced Signal.

   Unlike startWithSignal(_:), the caller is responsible of invoking the post-creation side effect i.e. didCreate. The swap in responsibility here gives a room of optimisation for lifted Signal operators. They can now dodge the unnecessary relay Signal that would otherwise be created by the old startWithSignal(_:).

4. Condensed the description of SignalProducer.

Result

For every lifted Signal operator applied, one less Signal would be produced. So given a producer chain SignalProducer(signal).map.map.map, it would now produce a graph of four Signals, instead of seven.

[andersio]

These trampolines are made as liftLeft and liftRight cannot be included in SignalProducerProtocol (except the unary lift). Having said that, these trampolines can be removed when Swift 3.1 lands, should we drop the protocol in favour of concrete same-type requirements.

[andersio]

It seems intermediate signals do not get interrupted events but are disposed of directly. Fixing. Fixed.

[mdiep]

The idea here makes sense: why create more signals than are needed? But I find the implementation here to be difficult to follow. I think we need to try to clarify/simplify the code before merging. I'll swing back around to this after we get 1.0 out (or at least until we get 1.0 PRs merged).

[andersio]

Not in a hurry. Gotta think of a better explanation to all this. ☕

[andersio]

I think we need to try to clarify/simplify the code before merging.

I do hope to figure out a way to unify both "modes" to burn down the giant switch in the binary lift. But I have my hands busy on other stuff right now. 🐝

[andersio]

Heh, it turns out to be quite straightforward. 🙈

[mdiep]

Trying to get to this. It's on my list 😅

[andersio]

Note that this addressed #227, since now downstreams are interrupted by upstreams. IOW interrupted would now respect the async operators applied.

[mdiep]

I think the language was clearer before. Specifically this bit:

where each invocation of start() will create a new underlying operation.

[mdiep]

I guess this needs a merge from master?

[mdiep]

I think this would be clearer as a typealias.

typealias Builder = () -> (signal: Signal<Value, Error>, didCreate: () -> Void, interruptHandle: Disposable)

Or maybe a struct instead of a tuple for the return value:

struct Instance {
  var signal: Signal<Value, Error>
  var didCreate: () -> Void
  var interruptHandle: Disposable
}
let builder: () -> Instance

[mdiep]

Basically: this could be return SignalProducer<U, F> { ... }.

[mdiep]

Sorry this one took so long! 😅