Reactivecocoa: Remove `SignalProducer(values: Value...)`

[mdiep]

It's leading to incorrect (or perhaps more accurately _unexpected_) type inference, as demonstrated by this example that was shared in Slack:

let activeSignal = NSNotificationCenter.defaultCenter()
         .rac_notifications(UIApplicationDidBecomeActiveNotification, object: nil)

let backgroundSignal = NSNotificationCenter.defaultCenter()
         .rac_notifications(UIApplicationDidEnterBackgroundNotification, object: nil)

let stateSignal: SignalProducer<NSNotification, NoError> = SignalProducer(values: [activeSignal, backgroundSignal])
   .flatten(.Merge)

stateSignal
   .on(completed: {
      print("completed")
   })
   .startWithNext {
      _ in
      print("next")
}

let stateSignal2 = SignalProducer(values: [activeSignal, backgroundSignal])
   .flatten(.Merge)

stateSignal2
   .on(completed: {
      print("completed2")
      })
   .startWithNext {
      _ in
      print("next2")
}

stateSignal2 is using that initializer and creating a SignalProducer<[SignalProducer<NSNotification, NoError>], NoError> that gets flattened into a SignalProducer<SignalProducer<NSNotification, NoError>, NoError>

[ikesyo]

https://github.com/Carthage/Carthage/pull/1329/files#r65486309 would be related.

[filblue]

+1 for removing, IMO this sugary overload simply pollutes the API. Why mixing SequenceType and sequential streams semantics?

[NachoSoto]

:+1:

[ikesyo]

How about the signature:

public init(values first: Value, _ second: Value, _ tail: Value...) {
    self.init(values: [ first, second ] + tail)
}

This requires at least two elements, so the initializer can be distinguished from public init<S: SequenceType where S.Generator.Element == Value>(values: S). It might be possible to introduce the change to 4.x as just a bug fix.

[liscio]

Just so we have a tl;dr explanation in here, this proposes that we remove the SignalProducer(values: Value...) but still _retain_ the SignalProducer<S: SequenceType>(values: S), correct?

[mdiep]

Fixed by @ikesyo in #3043. 👏🏻

[mdiep]

Just so we have a tl;dr explanation in here, this proposes that we remove the SignalProducer(values: Value...) but still retain the SignalProducer(values: S), correct?

That was the proposal, but @ikesyo fixed the ambiguity.