Make non-class types be able to conforms to ReactiveExtensionProvider

[ra1028]

This is very tiny changes.

Checklist

• Updated CHANGELOG.md.

[mdiep]

I know there's been some discussion of removing this requirement before. Can you share an example of a non-class type where you'd like to use it?

[ra1028]

e.g, want to use reactive extension for another extension host.
Do we need to restrict to class type?

public protocol ExtensionsProvider: class {}

public extension ExtensionsProvider {
    var extensions: Extension<Self> {
        return Extension(self)
    }
    
    static var extensions: Extension<Self>.Type {
        return Extension<Self>.self
    }
}

public struct Extension<Base> {
    public let base: Base
    
    fileprivate init(_ base: Base) {
        self.base = base
    }
}

extension UIView: ExtensionsProvider {}

public extension Extension where Base: UIView {
    func fooString() -> String {
        return "foo"
    }
}

extension Extension: ReactiveExtensionsProvider {}

public extension Reactive where Base == Extension<UIView> {
    func fooString() -> SignalProducer<String, NoError> {
        return SignalProducer(value: base.fooString())
    }
}

[mdiep]

I'm not sure this is something that we want to support.

Reactive extensions only really make sense with a reference type. If you were trying to change a struct or enum, you'd have problems. I'm not sure if enabling other wrappers like this is worth it given that it might be confusing to users.

@ReactiveCocoa/reactivecocoa?

[sharplet]

I have had this particular use case before when writing extensions for Kingfisher, which uses a .kf extension provider for its UIKit wrapper functionality. The value returned from .kf is a class, which explains why I didn't have this limitation.

I'm not currently opposed to loosening the restriction, although as you say it doesn't make a lot of sense for binding targets. @mdiep is that the confusion you're thinking of? That users might make a binding target to a struct and then be confused that it doesn't mutate shared state?

[mdiep]

@mdiep is that the confusion you're thinking of? That users might make a binding target to a struct and then be confused that it doesn't mutate shared state?

Yup.

[andersio]

That users might make a binding target to a struct and then be confused that it doesn't mutate shared state?

This is unlikely to happen since BindingTarget does not support inout reference. So if the host is value type, mutations attempted in the closure would be blocked by the compiler (unless the enclosing declaration has the mutating modifier).

Either way, this is a semantic error that IMO we shouldn't account for.

[ra1028]

Either way, this is a semantic error that IMO we shouldn't account for.

Agreed.

@mdiep
How about?