New answers tagged

2

The problem is the use of a nonisolated function to initiate an asynchronous update of an actor-isolated property. (I'm surprised the compiler even permits that.) Not only is it misleading, but actors also feature reentrancy, and you introduce all sorts of unintended races. However, you can add an actor-isolated function to Limiter: func submit(task: @...


0

The proposed approach hangs both on iOS and macOS (just not in unit tests executed in parallel), which is fascinating in its own right. See inline comments: @main struct BlockerApp: App { @State var count = 0 var body: some Scene { WindowGroup { VStack { Text("\(count)") ...


2

I know that you were contemplating this as merely a temporary step in the process of the migration, but I would discourage the use of this pattern at all. Semaphores are unsafe to use with Swift concurrency. In WWDC 2021 video Swift concurrency: Behind the scenes, Apple discusses the need to “preserve the runtime contract” and ensure “forward progress”, and ...


1

Yes, this looks fine re KVO and thread-safety. A few stylistic observations: I would personally move the willChangeValue and didChangeValue into the setters. It feels a little cluttered to have them sprinkled about the implementation. This pattern in your code snippet harkens back to the original Objective-C implementation, but Swift provides us ...


Top 50 recent answers are included