SE-0304 (2nd review): Structured Concurrency

Some quick feedback on the proposal, I apologize for being after the official review cycle:

  • I love the improvements from v1 of the proposal. Moving things out of Task is much more clear.
  • I agree with other comments that the priority names should be generalized, even if they remain a small number of integers. This proposal seems reasonable to me.
  • I think that standardizing around the term spawn is a good way to go, but I'd recommend going further and pulling it into the detatch method. Instead of:
let dinnerHandle = detach {
  try await makeDinner()
}

I think it would be more fluent and would avoid introducing another top-level verb if we used:

let dinnerHandle = spawnDetached {
  try await makeDinner()
}

It seems ok to make the unstructured concurrency API more verbose since we prefer structured concurrency. This also maintains alignment around the spawn verb. Another alternative is detatchTask, but I think that aligning with spawn is a better way to go. You could go really crazy and use spawnDetatchedTask I suppose.

  • With the introduction of effectful properties, should get() in let dinner = try await dinnerHandle.get() be an async get-only property, e.g. let dinner = try await dinnerHandle.value? The corresponding getResult() would just be .result. This aligns with the general cocoa naming convention which doesn't like "get" methods.

  • On withTaskCancellationHandler I agree that putting the cancelation handler second and using something like onCancel seems most consistent with other frameworks and with do/catch syntax.

Overall, this is really great work, I'm excited to see it coming into Swift!

-Chris

12 Likes