Dependency with main actor-isolated initializer requirements like FeedbackGeneratorClient from isowords

[ph1ps]

Hello,

I was trying to extract UISelectionFeedbackGenerator into its own dependency like it is in isowords.
Very similar to isowords, the client itself looks like this:

public struct FeedbackGeneratorClient: Sendable {
  
  public internal(set) var prepare: @Sendable () async -> Void
  public internal(set) var generate: @Sendable () async -> Void
  
  public init(
    prepare: @escaping @Sendable () async -> Void,
    generate: @escaping @Sendable () async -> Void
  ) {
    self.prepare = prepare
    self.generate = generate
  }
}

extension DependencyValues {
  
  public var feedbackGeneratorClient: FeedbackGeneratorClient {
    get { self[FeedbackGeneratorClient.self] }
    set { self[FeedbackGeneratorClient.self] = newValue }
  }
}

And the live implementation looks like this:

extension FeedbackGeneratorClient: DependencyKey {
  
  public static let liveValue = {
    
    let selectionFeedbackGenerator = UISelectionFeedbackGenerator() // 🔴 Call to main actor-isolated initializer 'init()' in a synchronous nonisolated context

    return Self(
      prepare: { await selectionFeedbackGenerator.prepare() },
      generate: { await selectionFeedbackGenerator.selectionChanged() }
    )
  }()
}

However if you have -warn-concurrency enabled, there will be a compilation error at the line I marked. I think I understand what the compiler is trying to tell me, however I did not find a nice solution yet on how to handle this (without disabling the concurrency "warnings" of course 😅). Has someone else experienced something similar to this yet?

Maybe something like a MainActorIsolated similar to ActorIsolated and LockIsolated would make sense here?

[tgrapperon]

Hey @ph1ps, you're right, it is indeed really annoying to wrap main actor stuff with the protocol requirement getting in the way.
I have a MainActorIsolated wrapper that I'm toying with to tackle these issues:

public final class MainActorIsolated<Value: AnyObject>: @unchecked Sendable {
  @MainActor
  public private(set) lazy var value: Value = initialValue()
  private let initialValue: @MainActor @Sendable () -> Value
  public init(_ initialValue: @MainActor @Sendable @escaping () -> Value) {
    self.initialValue = initialValue
  }
  
  @MainActor
  public func withValue<T: Sendable>(
    _ operation: @MainActor (inout Value) throws -> T
  ) rethrows -> T {
    return try operation(&value)
  }
  
  @MainActor
  public subscript<Subject: Sendable>(dynamicMember keyPath: KeyPath<Value, Subject>) -> Subject {
    self.value[keyPath: keyPath]
  }
}

Because the value is only lazily created in a MainActor context, you can create values of this type synchronously everywhere. It would allow to conveniently wrap UISelectionFeedbackGenerator() as MainActorIsolated({ UISelectionFeedbackGenerator() }) (I think that we can't use an @autoclosure, but I may be wrong).

I was planning to add this utility to swift-dependencies-additions very soon, but if Brandon and Stephen prefer, I can directly PR on swift-dependencies.

[tgrapperon]

This very minimal version looks like to be enough to build witness-style dependencies:

public final class MainActorIsolated<Value: Sendable>: @unchecked Sendable {
  @MainActor
  public lazy var value: Value = initialValue()
  private let initialValue: @MainActor @Sendable () -> Value
  public init(initialValue: @MainActor @Sendable @escaping () -> Value) {
    self.initialValue = initialValue
  }
}

[ph1ps]

I am wondering why there is a warning when you remove the @unchecked:

🟡 Stored property '$_lazy_storage$_value' of 'Sendable'-conforming generic class 'MainActorIsolated1' is mutable

Actor isolated vars are safe in this context, aren't they? Maybe a frontend bug for lazy vars?

[tgrapperon]

Yeah, I'm not really sure if the lazy assignation will happen on the MainActor or not, so the unchecked is maybe unjustified. But this can be refactored using a computed property:

public final class MainActorIsolated<Value: Sendable>: @unchecked Sendable {
  @MainActor // I don't think we need this.
  private var _value: Value!
  @MainActor
  public var value: Value {
    get {
      if _value == nil { _value = initialValue() }
      return _value
    }
    set { _value = newValue }
  }
  private let initialValue: @MainActor @Sendable () -> Value
  public init(initialValue: @MainActor @Sendable @escaping () -> Value) {
    self.initialValue = initialValue
  }
}

We still need the @unchecked annotation, but this one is safe I guess.

[tgrapperon]

Alternatively, this one is Sendable without any warning:

@MainActor
public final class MainActorIsolated<Value>: Sendable {
  public lazy var value: Value = initialValue()
  private let initialValue: @MainActor () -> Value
  nonisolated public init(initialValue: @MainActor @escaping () -> Value) {
    self.initialValue = initialValue
  }
}

https://github.com/apple/swift-evolution/blob/main/proposals/0316-global-actors.md#using-global-actors-on-a-type

A non-protocol type that is annotated with a global actor implicitly conforms to Sendable. Instances of such types are safe to share across concurrency domains because access to their state is guarded by the global actor.

[filiplazov]

Hey @tgrapperon have you used this in your projects so far?
I am hit with a similar use case (not completely same) where I want to have a shared state dependency like

@MainActor
final class SharedStuff {
  var someInt: Int
}

The main purpose of this dependency is to share some state across many reducers but I want to restrict mutation to the main actor. What is the recommended approach for this?

[kamcma]

Alternatively, this one is Sendable without any warning:

@MainActor
public final class MainActorIsolated<Value>: Sendable {
  public lazy var value: Value = initialValue()
  private let initialValue: @MainActor () -> Value
  nonisolated public init(initialValue: @MainActor @escaping () -> Value) {
    self.initialValue = initialValue
  }
}

Hello all. Been working on a dependency with the same issue: needing to initialize resources on the main actor. Unfortunately, the quoted suggestion is now warning for me on Xcode 15.3 / Swift 5.10 / .enableExperimentalFeature("StrictConcurrency"):

@MainActor
public final class MainActorIsolated<Value>: Sendable {
  public lazy var value: Value = initialValue() // ⚠️ Non-sendable type '@MainActor () -> Value' in asynchronous access to main actor-isolated property 'initialValue' cannot cross actor boundary
  private let initialValue: @MainActor () -> Value
  nonisolated public init(initialValue: @MainActor @escaping () -> Value) {
    self.initialValue = initialValue // ⚠️ Main actor-isolated property 'initialValue' can not be mutated from a non-isolated context; this is an error in Swift 6
  }
}

Was playing around, trying to come up with a solution to this problem. What about something like this? Gives me no warnings.

struct LocationClient: Sendable {
  var requestLocation: @Sendable () async -> Void
  // etc
}

extension LocationClient: DependencyKey {
  public static var liveValue: Self {
    Self(
      requestLocation: { @MainActor in
        Self.manager.requestLocation()
      }
      // etc
    )
  }

  @MainActor
  private static let manager = {
    let manager = CLLocationManager()
    // configure resources if necessary
    return manager
  }()
}

Not sure if there's a way to extract the main-actor-static isolation into a wrapper type that doesn't warn; could save needing to annotate every endpoint closure @MainActor

Got the idea to store resources as statics on the client from isowords' Game Center client.

[ph1ps]

To fix the warnings you could just mark the closures @sendable like this:

@MainActor
public final class MainActorIsolated<Value>: Sendable {
  public lazy var value: Value = initialValue()
  private let initialValue: @Sendable @MainActor () -> Value
  nonisolated public init(initialValue: @escaping @Sendable @MainActor () -> Value) {
    self.initialValue = initialValue
  }
}

But I like your approach. Definitely simpler.

[kamcma]

Ah, thank you for the pointer about fixing those warnings. Alright, well now I have some options. I will continue to think on it.

[kamcma]

Important caveat on my solution for anyone reading along at home: apparently static let main actor isolation is broken before Swift 5.10: swiftlang/swift#69607

[jtbergman]

Adding on to an old discussion, but this solution seems to work in Swift 6 language mode. I'm using this solution to share a TCA store via @Dependency which also faces the MainActor isolated initializer issue.

I introduced this type which is not isolated:

struct Provider<T>: Sendable {
  private let provide: @MainActor () -> T
  
  init(_ provide: @autoclosure @MainActor @escaping () -> T) {
    self.provide = provide
  }
  
  @MainActor func callAsFunction() -> T {
    provide()
  }
}

Then I register the dependency like any other.

extension DependencyValues {
  var feature: Provider<StoreOf<Feature>> {
    get { self[Feature.self] }
    set { self[Feature.self] = newValue }
  }
}

extension Feature: DependencyKey {
  // Need to use a static instance for the live value
  @MainActor private static let shared = StoreOf<Feature>(initialState: Feature.State()) { 
    Feature()
  }

  static let liveValue: Provider<StoreOf<Feature>> = Provider(Self.shared)
}

And finally, it can be used anywhere, but the key path must be invoked (i.e. \.feature()):

// Usage off MainActor
final class MainActorDependency {
  @Dependency(\.feature()) var feature
  
  func testing() async {
    print(await feature.state)
    await feature(.action)
  }
}

// Usage on MainActor
@MainActor 
final class SimpleUseFromMain {
  @Dependency(\.feature()) var feature
  
  func executesOnMain() {
    print(feature.state)
    feature.send(.action)
  }
}

[mbrandonw]

Hi @jtbergman, have you found that this actually works at runtime? It just crashes for me instantly:

Most likely just a Swift bug, but are you not seeing the same crash?

[jtbergman]

Oof, somewhere in my testing I switched to recompiling the module to save time and missed the runtime issue that was introduced 😅 I was actually surprised the code compiled after adding the callAsFunction and doing \.feature(), so I guess it makes sense it's causing a runtime crash. I'm guessing it's a Swift bug that it is allowed to compile.

The approach can work at runtime, but it's no longer convenient. It just requires invoking feature() on a separate line.

// MainActor - won't crash at runtime
Task { @MainActor in
  @Dependency(\.feature) var feature
  let store = feature()
  store.send(.greet)
  print(await store.state)
}

// Detached – won't crash at runtime
Task.detached {
  @Dependency(\.feature) var feature
  let store = await feature()
  await store.send(.greet)
  print(await store.state)
}

Access to properties can be made more convenient using @dynamicMemberLookup.

@dynamicMemberLookup
struct Provider<T: Sendable>: Sendable {
  ...

  @MainActor var value: T {
    provide()
  }
  
  @MainActor subscript<U>(dynamicMember keyPath: KeyPath<T, U>) -> U {
    value[keyPath: keyPath]
  }
}

// Only makes MainActor access more convenient
Task { @MainActor in 
  @Dependency(\.feature) var feature
  print(feature.state) // No need to invoke feature()
}

// Off MainActor
// ❌ Non-Sendable type 'KeyPath<Store<Feature.State, Feature.Action>, Feature.State>' cannot be sent into main actor-isolated context in call to subscript 'subscript(dynamicMember:)'
Task.detached { 
  @Dependency(\.feature) var feature
  print(await feature.state)
}

And you can't call methods conveniently without accessing value directly or invoking feature() to get the provided dependency. In the case of TCA stores, it would be nice to provide something like the following, but I think that relies on parameterized extensions, so it's not possible today.

// Not possible today? 
extension<S, A> Provider where T = Store<S, A>  {
  @MainActor func send(_ action: A)
    value.send(action)
  }
}

So I guess if I had to use this approach, I would use the original code without the dynamic member lookup, and just grabbing the dependency on a separate line so it's consistent on/off main and accessing properties/invoking methods. But definitely not as convenient anymore :/

Thanks for flagging the issue 🙏

[mbrandonw]

  let store = feature()
  store.send(.greet)

You have to be careful with this syntax because it could lead you to creating a whole new store each time feature() is invoked. You will want to make sure your Provider only captures a fully realized value and not a lazily created value to avoid that, and that may defeat the purpose.

// Not possible today? 
extension<S, A> Provider where T = Store<S, A>  {
  @MainActor func send(_ action: A)
    value.send(action)
  }
}

You can write this as:

extension Provider {
  @MainActor func send<S, A>(_ action: A) where T == Store<S, A> {
    value.send(action)
  }
}

But I'm still unsure of the overall pattern being employed here.