Convert free functions to static functions

[mdiep]

Should non-instance methods be free functions or static functions?

Because currently we have:

extension SignalType {

    /// Merges the given signals into a single `Signal` that will emit all values
    /// from each of them, and complete when all of them have completed.
    @warn_unused_result(message="Did you forget to call `observe` on the signal?")
    public static func merge<S : SequenceType where S.Generator.Element == Signal<Value, Error>>(signals: S) -> ReactiveCocoa.Signal<Self.Value, Self.Error>
}

But we also have:

/// Combines the values of all the given signals, in the manner described by
/// `combineLatestWith`.
@warn_unused_result(message="Did you forget to call `observe` on the signal?")
public func combineLatest<A, B, Error>(a: Signal<A, Error>, _ b: Signal<B, Error>) -> Signal.Signal<(A, B), Error>

We should standardize on one or the other for RAC 5.0.

I'd vote free functions, but I'm curious if someone thinks we should be using static functions. @ReactiveCocoa/reactivecocoa

[JaviSoto]

Static functions are more autocomplete-friendly, so I would vote for that.
Thanks for bringing this up :) definitely agree we should unify for consistency!

[mdiep]

A benefit of free functions is that you don't need to think about whether something is a Signal or a SignalProducer.

[RuiAAPeres]

I agree with @JaviSoto. For people that know RAC well, free functions are not an issue, I would argue for novice to mid level discoverability can be an issue.

[andymatuschak]

The Swift API guidelines are pretty clear on this.

Prefer methods and properties to free functions. Free functions are used only in special cases:

When there’s no obvious self:
min(x, y, z)

When the function is an unconstrained generic:
print(x)

When function syntax is part of the established domain notation:
sin(x)

These functions are basically fancy constructors, so using the metatype as self seems plenty defensible.

[mdiep]

This was done in #3001! 🎉