Proposal: Label the output and input ends of Signal.pipe()

[sharplet]

This is in part inspired by the API Design Guidelines: https://swift.org/documentation/api-design-guidelines/#label-closure-parameters.

Attempts to clarify usage by being more explicit about the input and output ends of the signal "pipe", and rewords the documentation accordingly.

[liscio]

I almost feel like it'd make more sense to have Signal.pipe() just return a new type (like Pipe) that works similarly to a RACSubject stand-in.

It'd just be a struct that holds input and output, or signal and observer, but we could take it further and have it conform to the right protocols so it'd behave like the old RACSubject so we can use operators with it directly. 😛

[sharplet]

In general I think I agree with that direction. This particular change has the advantage of being non-breaking—however, if we'd like to go down the road of adding a real type for this concept, it may make sense to break it for 1.0. Thoughts, @ReactiveCocoa/reactiveswift?

[andersio]

Adding labels to tuples is addictive and straightforward. If it gets merged before #137 then it would be in 1.0.

Introducing a new type is however breaking, and I'd prefer to leave that to 2.0, which is just a few months away anyway.

#147

[mdiep]

The tests need to be updated. Which is surprising to me because I thought these names were no longer part of the type. 😕

This makes sense to me. 👍 But I'd like to see it with passing tests to verify that my assumptions about how it works are correct.

[sharplet]

I've pushed a fix for the tests.

I thought these names were no longer part of the type

What I found was that if I removed labels from the Pipe typealias, things compiled as expected (i.e., the labelled and unlabelled versions of the tuple were treated as compatible). So the error we were seeing appears to result from assigning a labelled tuple to a differently-labelled tuple.

So this change will break any clients who've used a typealias to add their own labels to this tuple.

[andersio]

Seems like this would be a 2.0 thing then.

[mdiep]

I'm okay with merging this as a last-minute fix for 1.0. Thoughts?

[sharplet]

My guess is that this will have a low impact in practice, so I'm in board with including it for 1.0.