Composing actions: how to do something like "firstEnabled"?

[tikitu]

I have two Actions with the same input/output/error types, and I'd like to compose them into a single Action that runs whichever of the two is enabled (with an arbitrary tie-breaker if they both are).

Here's my first, failing, attempt:

let addOrRemove: Action<MyInput, MyOutput, APIRequestError> = Action(enabledIf: add.isEnabled.or(remove.isEnabled)) { input in
    if add.isEnabled.value {
        return add.apply(input)
    } else {
        return remove.apply(input)
    }
}

This fails because the inner add.apply(input) can't see that I checked add.isEnabled, so it wraps an additional ActionError<> layer around the error type. (This might be legit, as I'm not sure how thread-safe this approach would be, or might be a case of us knowing something the type system doesn't.) The corresponding type error is:

cannot convert return expression of type 'SignalProducer<MyOutput, ActionError<APIRequestError>>' to return type 'SignalProducer<MyOutput, APIRequestError>'

What would y'all suggest as a better approach?

I've asked this on Stack Overflow as well, might be a better venue: http://stackoverflow.com/q/43888981/323083

[ikesyo]

How about this?

let producer: SignalProducer<MyOutput, ActionError<APIRequestError>>
if add.isEnabled.value {
    producer = add.apply(input)
} else {
    producer = remove.apply(input)
}
return producer.flatMapError { error in
    switch error {
    case .disabled: return .empty
    case let .producerFailed(inner): return SignalProducer(error: inner)
    }
}

[tikitu]

Typechecks and my tests pass! Thanks @ikesyo, and I'm learning by studying this too. If you want SO cred I'll happily accept this as an answer over there too.

If I understand correctly, this assumes the .disabled case will never occur. Just for interest I wonder if this is (multithreading-)guaranteed, or just very unlikely?

[tikitu]

I think I can answer my own question: if add is enabled when we call apply() but disabled by the time we call start(), we'll hit the .disabled case: in that case I think we'll report success (no values, but .completed) on the outer Action, instead of the disabled we should be getting. It's good enough for me, but I still wonder if there's a way to do this "properly" -- possibly not, as I guess it would require access to private internals of Action.

[tikitu]

And for completeness: I ended up with the following, which I think improves slightly on the correctness of the original solution (by checking if add.isEnabled at start() time as well as apply() time). (It does double apply() work, but that shouldn't trigger side-effects I believe. Avoidable with @autoclosure I expect, if it worries you.) Drive-by readers please note I'm no expert, so write your own test cases.

func firstEnabledAction<Input, Output, Err>(
    _ first: Action<Input, Output, Err>,
    _ second: Action<Input, Output, Err>) -> Action<Input, Output, Err> {
    func whenDisabled(_ producer: SignalProducer<Output, ActionError<Err>>,
                      fallBackTo fallback: SignalProducer<Output, Err>) -> SignalProducer<Output, Err> {
        return producer.flatMapError {
            switch $0 {
            case .disabled:
                return fallback
            case .producerFailed(let inner):
                return SignalProducer(error: inner)
            }
        }
    }
    return Action(enabledIf: first.isEnabled.or(second.isEnabled)) { input in
        return whenDisabled(first.apply(input), 
                            fallBackTo: whenDisabled(second.apply(input), 
                                                     fallBackTo: .empty))
    }
}