I'm not sure how useful this would end up being nor how much can actually be done given the constraints involved (such as the impossibility to know at runtime how many elements a Swift tuple holds, etc.).
However, I thought I'd have a look to see what could be done. If I finish anything that looks reasonable, I'll create a pull request.
Being able to bridge a RACTwoTuple<NSString, NSNumber> into (NSString, NSNumber) would be quite useful. For instance when we have bridged our RACSignal<RACTwoTuple<NSString, NSNumber>> (do we actually retain nested types like this? I'm not sure) to a SignalProducer<RACTwoTuple<NSString, NSNumber>, NSError>, it'd make it easy to map that to get a SignalProducer<(NSString, NSNumber), NSError>.
Being able to turn a (String, Bool) into a RACTwoTuple<NSString, NSNumber> would also be useful when bridging to RACSignal.
erichoracek
commented
7 years ago
I'm not sure how useful this would end up being nor how much can actually be done given the constraints involved (such as the impossibility to know at runtime how many elements a Swift tuple holds, etc.).
However, I thought I'd have a look to see what could be done. If I finish anything that looks reasonable, I'll create a pull request.
Being able to bridge a
RACTwoTuple<NSString, NSNumber>into(NSString, NSNumber)would be quite useful. For instance when we have bridged ourRACSignal<RACTwoTuple<NSString, NSNumber>>(do we actually retain nested types like this? I'm not sure) to aSignalProducer<RACTwoTuple<NSString, NSNumber>, NSError>, it'd make it easy to map that to get aSignalProducer<(NSString, NSNumber), NSError>.Being able to turn a
(String, Bool)into aRACTwoTuple<NSString, NSNumber>would also be useful when bridging toRACSignal.