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: apple/swift#69607