`async let` and scoped suspension points

[Karl]

@Joe_Groff

func example2() async throws {
  async let x = foo()

  try somethingThatMightThrow()

  // error: `x` not read if `somethingThatMightThrow` throws
  use(await x)
}

This is the most compelling example, IMO. I don’t see how the second proposed solution (await on scopes) would solve this problem. Which means…

@Joe_Groff

2. A suspension may occur on scope exit if the scope contains async
   statements or declarations.

This rule would accommodate async let today, and makes space in the language
to introduce other features with scoped implicit suspension points.

I think that this kind of solution is the only one that is really workable. When your principles don’t fit reality, sometimes you need to change your principles.

However, I do feel that, as written, it is probably over-generalising. Most developers won’t understand/remember what an “async statement or declaration” is - does it mean calling or declaring an async function? What about the async global function? DispatchQueue.async? Any of the other hundreds of APIs in 3rd-party libraries which have “async” somewhere in the name?

The word ‘async’ is used so broadly that it is probably unwise to attach this kind of specific meaning to it.