Chaing onChange to BindingReducer seems to not be working... Should it?

[wshamp]

Bringing this here from Slack. I was trying to observe two @BindingState properties and the compiler gives me the old unable to type check routine. Just curious if this should work or not. Here is a real simple example that the compiler blows up on.

struct OnChangeTestFeaure: Reducer {
    struct State {
        @BindingState var test1: Int
        @BindingState var test2: Int
    }
    enum Action: BindableAction {
        case binding(BindingAction<State>)
    }
    var body: some ReducerOf<Self> {
        BindingReducer()
            .onChange(of: \.test1, removeDuplicates: ==) { oldValue, newValue in

            }
            .onChange(of: \.test2, removeDuplicates: ==) { oldValue, newValue in

            }
        Reduce { state, action in
            switch action {
            case .binding:
                return .none
            }
        }
    }
}

[wshamp]

So apparently removing on of the removeDuplicates allows this to compile. Not sure why.

[acosmicflamingo]

Are bindings equatable? The comparison isn't between two integers but two bindings of integers.

I don't know what I'm talking about LOL I was just glancing at the code and when I saw your response, I recalled instances when I got issues like these because I didn't realize something else was being compared.

[mbrandonw]

Hi @wshamp, I'm not sure there is much we can do here. It just seems like Swift has a problem compiling these expressions, and I think the removeDuplicates exacerbates the problem. Maybe this is why the vanilla SwiftUI onChange view modifier requires Equatable and does not provide a removeDuplicates option.

I was even able to reproduce the problem in vanilla SwiftUI with the onChange view modifier. I added an overload that takes a removeDuplicates argument, and if I chain on 3 of them in a view the Swift compiler can't handle it:

struct V: View {
  @State var value = 0
  var body: some View {
    Form {
    }
    .onChange(of: value, removeDuplicates: ==) { oldValue, newValue in
    }
    .onChange(of: value, removeDuplicates: ==) { oldValue, newValue in
    }
    .onChange(of: value, removeDuplicates: ==) { oldValue, newValue in
    }
  }
}
extension View {
  public func onChange<V>(
    of value: V,
    removeDuplicates: (V, V) -> Bool,
    @ViewBuilder _ action: @escaping (_ oldValue: V, _ newValue: V) -> some View
  ) -> some View {
    EmptyView()
  }
}

So, perhaps we should get rid of the removeDuplicates version of Reducer.onChange, and in the meantime I would stay away from it.

[pyrtsa]

@wshamp Looks like you can work around the slow type checking by disambiguating each overload of ==:

         BindingReducer()
-            .onChange(of: \.test1, removeDuplicates: ==) { oldValue, newValue in
+            .onChange(of: \.test1, removeDuplicates: (==) as (Int, Int) -> Bool) { oldValue, newValue in
 
             }
-            .onChange(of: \.test1, removeDuplicates: ==) { oldValue, newValue in
+            .onChange(of: \.test1, removeDuplicates: (==) as (Int, Int) -> Bool) { oldValue, newValue in
 
             }

The same workaround fixes the vanilla SwiftUI example as well, as does introducing a local closure let intsEqual: (Int, Int) -> Bool = (==) and passing that to removeDuplicates: intsEqual.

So, perhaps we should get rid of the removeDuplicates version of Reducer.onChange, and in the meantime I would stay away from it.

Maybe rather document this as temporary shortcoming with a known workaround, and report as a bug to Swift compiler?

[stephencelis]

@pyrtsa We think it's probably better to remove for now in favor of an interface that is known to work. The primary use case for this overload is tuples, which should eventually be equatable (we hope!), so we think in the meantime that creating an equatable wrapper type is a gentler solution for now.

#2744

[pyrtsa]

Fair! 👍