feat: SignalProducerConvertible actions

[maximkrouk]

This feature is needed for RAC-TCA https://github.com/trading-point/reactiveswift-composable-architecture/issues/23 This will enable framework users to use their custom types as SignalProducer In my case, I need to create @dynamicMemberLookup SignalProducer to use it like

state.property.subproperty.text.assign(to: \.text, on: label)
// equivalent to
state
    .map(\.property).skipRepeats()
    .map(\.subproperty).skipRepeats()
    .map(\.text).skipRepeats()
    .assign(to: \.text, on: label)

Checklist

• [x] Updated CHANGELOG.md.

[maximkrouk]

Well, it's not required anymore, but I think this feature would still be useful

[mluisbrown]

So basically this is just adding the SignalProducer API to anything that conforms to SignalProducerConvertible by doing .producer.<function> for every function in the API?

I like the idea, as it allows you to create your own SignalProducers (which is currently not possible because SignalProducer is a struct), in the similar way to creating your own Combine Publisher, which is possible since Publisher is a protocol.

The only downside I see is that the implementation requires that the entire SignalProducer API is replicated for SignalProducerConvertible 😕

[andersio]

Swift's generic system is argubly not expressive enough for ReactiveSwift to move away from the current model of type-erased currency types (Signal, SignalProducer and Property).

Without higher-kinded types, there isn't much to gain except for providing a shorthand for entity.producer.operator1() to be entity.operator1(). operator1(), as evidently, still returns SignalProducer in the end, with no type information of the upstream producer being carried down the line for downstream operators to constrain against.

as it allows you to create your own SignalProducers

You can already create your own SignalProducer through the anonymous closure. There is a performance argument to do this based on types + virtual dispatch (Combine/RxSwift), rather than anonymous closure (ReactiveSwift). But otherwise, there is no gain in expressivity as it stands.

[maximkrouk]

Without higher-kinded types.

This PR would enable users to write their own higher-kinded types, that was exactly what I needed, the package doesn't have to provide any, but that was unfortunate that I couldn't write my own 🌚

You can already create your own SignalProducer through the anonymous closure.

Yep, but this signal produced won't apply custom logic to it's operators

However I think this PR is too outdated, so I'm closing it :)