switch fails assert if the receiver sends nil

[Coneko]

If a subscribable sends nil, then switch fails it's assert:

NSAssert2([x conformsToProtocol:@protocol(RACSubscribable)], @"-switch requires that the source subscribable (%@) send subscribables. Instead we got: %@", self, x);

From a cursory glance at the code there doesn't seem to be any practical reason why nil wouldn't be a valid value.
Is requiring a non-nil subscribable a design choice or just something that never came up?

[jspahrsummers]

@joshaber can speak to whether this was an intentional design choice, but I'd argue that it's the correct one. A subscribable of subscribables shouldn't send nil, because references to subscribables just generally shouldn't be nil. If you need to represent a nil or empty value, create a subscribable that returns it immediately.

[Coneko]

I can see the logic behind that, and I would agree with it if it were an isolated matter, but it makes using subjects as properties a bit cumbersome.

Consider

[RACAble(self.object.subjectProperty) switch]

Even if whatever object is makes sure that subjectProperty is never set to nil, you'd still have to make sure the object property on self is never set to nil (and since object is not a subscribable itself, a nil value could make perfect sense), or use

[[[RACAble(self.object) where:^BOOL(id x) {
    return x != nil;
}] select: ^id(id x) {
    return [x subjectProperty];
}] switch]

instead.

The problem is compounded if you use subscribables that send objects that have subscribable properties.
A simple chain of select, switch and RACAble would have to be interspersed with where everywhere.
Even if it might not be strictly correct, I'd like to be able to switch nil subscribables because of this.

[jspahrsummers]

👍 Those are good points. I think -switch should be updated.

[joshaber]

Makes sense to me 👍 PR opened.

[Coneko]

Looks good, thanks for the fix and fast feedback.