public Dependency and Sendable conformance

[stickeejosh]

I have modularised my project using Swift Packages and my Dependencies are mostly public with live implementations in separate modules to tests.
When updating to Swift 6 language mode I have to declare these dependencies as Sendable, enforced by the requirement from TestDependencyKey.
When I use these dependencies in a .run Effect from a Reducer I have to explicitly capture the dependency I am using e.g.

@Dependency(\.myDependency) var myDependency

Reduce { state, action in 

  switch action {
    case .myAction:
      return .run { [myDependency] send in
        try await myDependency.myFunc()
      }
  }
}

In the VoiceMemos example project @DependencyClient struct AudioPlayerClient does not have to declare conformance to Sendable itself.
However, the same error can be seen by changing the AudioPlayerClient Dependency and VoiceMemo Reducer to public.

Capture of 'self' with non-sendable type 'VoiceMemo' in a @Sendable closure

This explicit Sendable conformance can be seen in TicTacToe's TwoFactor Reducer and AuthenticationClient Dependency.
Can someone help my understanding of Sendable requirements by explaining:

1. Why does the public scope of the Dependency and Reducer change the explicit Sendable declaration requirements?
2. Why does this affect the capture requirements in the Reducer's body?
3. Is the Dependency's and Reducer's sendability being inferred when it is only an internal scope?

Thanks

[lukeredpath]

Structs are only implicitly sendable when they are internal. It is by design that a public type needs an explicit Sendable conformance. This is outlined here: https://developer.apple.com/documentation/swift/sendable

You can avoid the issue of having to capture dependencies explicitly by making your reducer's conform to Sendable - if your reducer is not sendable then you cannot capture it in a sendable closure. In my experience, making your reducer sendable is simplest.

[OguzYuuksel]

I’m also considering making my reducer conform to Sendable.
Do we have any best-practice guidance on this? Would it make sense to add Sendable conformance directly to the Reducer protocol, or are there valid situations in which a reducer should remain non-sendable?