{"id":42307,"date":"2024-03-01T14:18:51","date_gmt":"2024-03-01T19:18:51","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=42307"},"modified":"2024-03-01T14:19:15","modified_gmt":"2024-03-01T19:19:15","slug":"where-view-task-gets-its-main-actor-isolation-from","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/03\/01\/where-view-task-gets-its-main-actor-isolation-from\/","title":{"rendered":"Where View.task Gets Its Main-actor Isolation From"},"content":{"rendered":"

Ole Begemann<\/a>:<\/p>\n

\n

SwiftUI’s .task<\/code> modifier<\/a> inherits its actor context from the surrounding function. If you call .task<\/code> inside a view’s body<\/code> property, the async operation will run on the main actor<\/a> because View.body<\/code> is (semi-secretly) annotated with @MainActor<\/code>. However, if you call .task<\/code> from a helper property or function that isn’t @MainActor<\/code>-annotated, the async operation will run in the cooperative thread pool.<\/p>\n

[…]<\/p>\n

    \n
  1. \n

    The View<\/code><\/a> protocol annotates its body<\/code><\/a> property with @MainActor<\/code>. This transfers to all conforming types.<\/p>\n <\/li>\n

  2. \n

    View.task<\/code><\/a> annotates its action<\/code> parameter with @_inheritActorContext<\/code><\/a>, causing it to adopt the actor context from its use site.<\/p>\n <\/li>\n<\/ol>\n\n

    Sadly, none of these annotations are visible in the SwiftUI documentation, making it very difficult to understand what’s going on. […] To really see the declarations the compiler sees, we need to look at SwiftUI’s module interface<\/em> file.<\/p>\n

    […]<\/p>\n

    When used outside of body<\/code>, there is no implicit @MainActor<\/code> annotation, so task<\/code> will run its operation on the cooperative thread pool by default. (Unless the view contains an @ObservedObject<\/code> or @StateObject<\/code> property, which somehow makes the entire view @MainActor<\/code>. But that’s a different topic.)<\/p>\n<\/blockquote>\n\n

    Der Teilweise<\/a>:<\/p>\n

    \n

    Swift concurrency is a mess.<\/p>\n

    Every software framework that tries to automagically do “the right thing” is doomed to break your code in the most unexpected way.<\/p>\n

    Add a new member variable and it changes execution of unrelated parts from concurrent to serial. How wild is this?<\/p>\n<\/blockquote>\n\n

    BJ Homer<\/a>:<\/p>\n

    Currently, we can infer @MainActor<\/code> on an entire type based on the presence of certain property wrappers within that type. TL;DR: I’m making a case that that’s a bad idea, and we should reconsider it if possible.<\/p><\/blockquote>\n\n

    Previously:<\/p>\n