Should BindingAction and BindableState conforming to Sendable?

[ikarishinjigao]

I got bunch of warnings when using binding feature (which is very useful) like the flowing with -warn-concurrency flag.

struct State: Equtable {
  // WARNING: Stored property '*' of 'Sendable'-conforming struct 'State' has non-sendable type 'BindableState<*>'
  @BindableState var someFeature: SomeFeature.State
  ...
}

enum Action: BindableAction, Equatable {
  // WARNING: Associated value 'binding' of 'Sendable'-conforming enum 'Action' has non-sendable type 'BindingAction<*>'
  case binding(BindingAction<State>
  ...
}

since the EffectPublisher.run require a Sendable operation, TCA's build-in BindingAction and BindableState should be conforming to Sendable too?
Simply add some extension like the flowing.

extension BindableState: Sendable where Value: Sendable {}
extension BindingAction: Sendable where Root: Sendable {}

By the way, AlertState and TextState also be warned.
I think those types should conforming Sendable as well.
But i'm not sure...

[mbrandonw]

Hi @ikarishinjigao, we might be able to make those types Sendable, but I'm curious how exactly you are getting the warnings. It should only happen if you are passing a BindingAction/BindableAction/TextState/AlertState/etc across a concurrent boundary, which I feel should be very rare. I can't think of a situation where it happens.

Can you share some code of how these warnings come up for you?>

[mbrandonw]

Yeah, I think the BindingAction type could be made sendable, and I guess it's forced by virtue of sending actions from effects.

But I'm not sure I see where BindableState, TextState, AlertState etc cause warnings. That would happen if storing those values in actions, but that seems strange. Are there other situations I'm overlooking?

[tgrapperon]

While I don't see a real case for directly onboarding a BindableState in an action, I already encountered situations where you want to onboard a State containing a BindableState (or a child containing a BindableState). For example, I'm receiving in a .task a huge array of POD data from the backend, from which I'm hydrating after processing an IdentifiedArrayOf<Child.State>, and produce a final action where this array is effectively stored in the domain's State:

return .task {
  await .childrenReceived(
    TaskResult<IdentifiedArrayOf<Child.State>> {
      let data = try await backend.retrieveData()
      let children = try await processDataIntoChildState(data)
	  return children
    }
  )
}

BindableState not being Sendable prevents automatic Sendable conformance for Child.State for example. I guess it's the same for TextState and AlertState, but I didn't check what it would require to be Sendable.

[mbrandonw]

Cool cool, thanks for the examples! Well, I do think there is a case to made for BindingAction and BindableState, and they should be easy to support.

I'm still not sure about TextState, AlertState, etc. The problem there is the use of Bundle in Text, but I think @stephencelis has some ideas for that. But we decided to punt on their sendability see we still aren't sure of where it is necessary.

[tgrapperon]

Great! There is also Color that is notoriously problematic, but in the meantime, there is also the UncheckedSendable property wrapper that can help in many cases for TextState and AlertState.

[ikarishinjigao]

Thanks for the explain and examples @tgrapperon !
In my case, I just make my reducers sendable, but it seems like is unnecessary at all. (sorry about that)