`BindingTarget.init` should probably take a `ReferenceWritableKeyPath`
UnidirectionalBinding.swift:188:
public init<Object: AnyObject>(on scheduler: Scheduler = ImmediateScheduler(), lifetime: Lifetime, object: Object, keyPath: WritableKeyPath<Object, Value>) {
self.init(on: scheduler, lifetime: lifetime) { [weak object] in object?[keyPath: keyPath] = $0 }
}
This code breaks under SE-0481, which changes weak captures to be immutable by default. I assume you do not actually mean to allow the reference to be replaceable by this assignment, but technically it can be: assignment to a WritableKeyPath is a mutating operation on self, and while you cannot write a property on a class type that mutates the self type, you can get one via a protocol extension of a non-class-restricted protocol that the class type conforms to.
The source-breaking-ness of SE-0481 is a problem for the Language Steering Group to decide, although we're certainly open to your input for how disruptive you think a source break for existing ReactiveSwift checkouts would be. (I'm guessing: quite disruptive.) But I thought you'd appreciate the heads-up that you might've done something you didn't intend.
Thanks for the heads up! Assuming that there is an easy fix we can implement then I don't think that a source break for existing ReactiveSwift checkouts would be that disruptive. Users would just need to update to a version of ReactiveSwift which has the fix.
Would making object an explicit weak var and then capturing that solve the source break?
For example:
public init<Object: AnyObject>(on scheduler: Scheduler = ImmediateScheduler(), lifetime: Lifetime, object: Object, keyPath: WritableKeyPath<Object, Value>) {
weak var mutableObject: Object? = object
return self.init(on: scheduler, lifetime: lifetime) { mutableObject?[keyPath: keyPath] = $0 }
}
Yes, that's the more direct fix, if changing the parameter to a ReferenceWritableKeyPath is wrong or if you're worried about changing the signature for clients.