Task "factory" functions, proper implementation?

[Kevin_Wooten]

TL;DR: Checking if it's ok to use @_inheritActorContext & @_implicitSelfCapture on a Task factory method.

We have started using Swift Concurrency heavily in our SDK and when integrating it with application code, rightfully, a good number of Tasks are created to call SDK methods. The SDK surfaces errors as much as possible to allow consuming code to handle them as they see fit and provide as much information as possible to the caller.

To that end we've created some Task factory methods that allow calling throwing functions and logs any errors thrown when used in a "terminal" context (e.g. in UI code). The factory methods simply create a Task with a do/catch that calls the passed in closure and log any thrown errors.

To gain the advantages of creating a Task "in context" we copied Tasks init method and added attributes @_inheritActorContext and @_implicitSelfCapture to our passed in operation closure.

We found that without these (especially @_inheritActorContext) that we are required to await methods that should not require it; e.g. calling @MainActor isolated functions from the @MainActor context; which seemingly is exactly what this @_inheritActorContext attribute is for.

I am just looking to make sure this is a valid thing to do in current and future Swift releases and learn of any pitfalls using them might create. They are currently working as expected but Concurrency is complicated and I am looking to be sure this is fundamentally correct code/usage.

Here is one of our implementation for examination...

@discardableResult
func spawn<TaskResult>(
  name: String = "Task",
  logger: Logger = taskLogger,
  type: OSLogType = .error,
  privacy: OSLogPrivacy = .private,
  @_inheritActorContext @_implicitSelfCapture operation: @escaping @Sendable () async throws -> TaskResult
) -> Task<TaskResult?, Never> {
  return Task {
    do {
      return try await operation()
    }
    catch {
      logger.error("\(name, privacy: .public) failed: error=\(error, privacy: privacy)")
      return nil
    }
  }
}

[SwiftedMind (Dennis Müller)]

This is also something I would love to know, it would make these factories/Task wrappers much more convenient to use, but I've not really seen @_inheritActorContext @_implicitSelfCapture in the wild yet.

I guess one risk is that underscored attributes are not technically stable and it is actively discouraged to use them (though I've seen many repositories use them anyways, like @_spi).

Edit: I found this quote about @_implicitSelfCapture in the review of SE-0304

@Douglas_Gregor

Explicit self is there for a specific purpose: to help identify retain cycles by requiring one to explicitly call out self capture where it's likely to cause retain cycles. We intentionally did not make it required everywhere , and then later we removed explicit self in other unlikely scenarios . When capturing self in a task, you effectively need the task to have an infinite loop for that capture to be the cause of a reference cycle. That fits very well with the direction already set for explicit self.

@Douglas_Gregor

It's an underscored attribute because we know we want this effect for the code running in a task, and that's why it's here in this proposal. It's not unlike the "marker protocol" for Sendable in that we know we want the effect, but we want more time to make it available for general use. We should have the discussion later about "dropping the underscore" from the attribute to make this a general feature that will help explicit self be meaningful, but we shouldn't make task creation worse while waiting for that discussion to happen.

Not sure if there's been more discussion on this.