Introducing Single type #2873

[RuiAAPeres]

This refers to ReactiveCocoa/Reactivecocoa/#2873

[liscio]

I don't see the value of having a new type to represent this.

As a consumer of an API like ReactiveSwift, I think it's nice and compact to think in terms of the two major constructs (Signal and SignalProducer). If you wanted to represent something like a Future using a Single, then I'd argue a SignalProducer makes far more sense because the caller is in control of kicking off the process that results in the value they are looking for. The same goes for SignalProducer.init(value:) or SignalProducer.init(error:)—it nicely captures the narrow scope of the created producer.

Furthermore, if the caller of an API vending a Signal{,Producer} is concerned about ensuring they only get a single value, then take(1) is a succinct way to assert exactly that in the code.

Perhaps a few examples of ReactiveSwift (pseudo-)code that'd be improved by Single would help sway my current 👎 attitude towards this. :)

[andersio]

I'd like to see if it could bring additional compile time guarantee over SignalProducer. AFAIK there is no way (and no plan) to have an attribute to guarantee that a closure can only be invoked once. So in the end, in terms of the static API contract it could very well be an equivalent of SignalProducer.

A new type also adds more overloads to our lifting-based operator model, and the maintenance cost has to be considered too.

[RuiAAPeres]

👍

[NachoSoto]

I'm also a big opponent of this idea (happy to explain why).

[mdiep]

I'd love to hear your thoughts @NachoSoto

[NinoScript]

I'm really interested in why this may not be a good idea. @NachoSoto ?

[RuiAAPeres]

ping @NachoSoto 😛

[andersio]

ping @NachoSoto 😸

[Qata]

ping @NachoSoto 🎊