promoteError type inference.

[andersio]

Preceded by #408.

This is useful when combining multiple signals with NoError in the mix, reducing the verbosity.

let (signal, _) = Signal<(), NoError>.pipe()

print(type(of: signal.promoteError(CocoaError.self)))
print(type(of: signal.promoteError()))
print(type(of: signal.promoteError() as Signal<(), CocoaError>))

// The promotion of the second operand is inferred.
print(type(of: Signal.zip(signal.promoteError(CocoaError.self), signal.promoteError())))

[NachoSoto]

Awesome

[NachoSoto]

Wait why is this overload necessary?

[andersio]

It isn't necessary, just that it allows one adds promoteError to everything in a brute force manner, while not yielding extra Signals in cases with the identical error types. Say if you do:

SignalProducer<Int, CocoaError>.combineLatest(
    SignalProducer<Int, CocoaError>.empty.promoteError(),
    SignalProducer<Int, NoError>.empty.promoteError()
)

The resulting Signal graph would be equivalent to:

SignalProducer<Int, CocoaError>.combineLatest(
    SignalProducer<Int, CocoaError>.empty,
    SignalProducer<Int, NoError>.empty.promoteError()
)

[NachoSoto]

I'm very much 👎 for that. Since when has RAC promoted brainless thinking? :P A user calling this operator when they shouldn't is likely an error and shouldn't be silenced IMO.

[andersio]

Perhaps I should be more careful about my wordings. The overload does not add any capability, and is just a fast path when the compiler knows Self.Error is the Error of the return producer.

Say SignalProducer<Int, CocoaError>.empty.promoteError(CocoaError.self).

[NachoSoto]

Oooh that's right, because it's not possible to do negative conditions on extensions. This is a great idea then 👍

[NachoSoto]

Ditto

[NachoSoto]

Can you add a test to cover this automatic inference?