-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make non-class types be able to conforms to ReactiveExtensionProvider #636
Make non-class types be able to conforms to ReactiveExtensionProvider #636
Conversation
9959727
to
c717fdb
Compare
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? |
e.g, want to use reactive extension for another extension host. 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())
}
} |
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 @ReactiveCocoa/reactivecocoa? |
I have had this particular use case before when writing extensions for Kingfisher, which uses a 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? |
Yup. |
This is unlikely to happen since Either way, this is a semantic error that IMO we shouldn't account for. |
Agreed. @mdiep |
This is very tiny changes.
Checklist