SE-0317: Async Let

[Chris_Lattner3 (Chris Lattner)]

@Paul_Cantrell

This whole dual meaning of async continues to bother me across all these proposals. These proposals use that same word for both:

1. indicating the presence of an effect and
2. creating a context that handles that effect.

This creates confusion for programmers around the crucial question of “Am I introducing concurrency, handling it, or indicating that my code here requires that the calling code handle it?” The word async can mean all these things.

As an analogy, consider what Swift would look like if we did the same thing for error handling, using the same word for both the effect and the context that handles it:

func createWidget(name: String) error -> Widget { ... }

let foo = error createWidget(name: "foo")

I completely agree. There are strong reasons why error handling has multiple "words in the lexicon": throws for the effect, try for the marker, Result for the "handle" type when erasing to an uneffectful function, and do/catch when introducing a new catch-processing region. I think that all these things are substantially different and are worth different "words" to clarify them.

@Joe_Groff

We should emphasize that being able to pass off a future for a child task is an anti-feature.

It depends on what you mean by this. The entire point of this feature is that /scoped/ concurrency is a valuable thing and that "passing off" is critical within that scope. This is analogous to what non-@escaping closures provide (in the non-concurrent domain). Neither allows escapability but both allow "passing off" down the call stack.

This is really the fundamental issue touched by this proposal: escapability. Swift doesn't have a first-class concept for this. It can't have a fully principled answer to this until we get to ownership, so we're all obliquely discussing tradeoffs about various approximations. We should bring this tradeoff discussion front and center if we want to get to the core of the issue.

My claim is that we should pick a short-term approximation that is absorbable into more general future language support -- rather than inventing weirdly-novel (in a bad way) language mechanics that will always have to be special even as the rest of the language develops. I'd rather we make a short term hack that dissolves away instead of overly polishing the special-case-of-the-day and living with it forever.

@Joe_Groff

Allowing handles to a child task to escape the scope of their parent task would break the guarantee we want to make about child tasks, that their lifetimes are always bounded by a scope,

Agreed 100x, this is true about a lot of computation and enables a lot of optimizations, e.g. the stack allocation optimization we already do for non-escaping closures. That's exactly the same thing we should do for child tasks. I'm arguing that we should embrace this as a general pattern instead of special casing it again.

@toph42

Does this feature allow for optional binding? Can you if async let ?

No, because the proposal is magic syntax that doesn't compose correctly with the meaning of let in other parts of the language. This is a very serious issue in my opinion and this symptom gets at the root of my concern about this proposal.

@Douglas_Gregor

try is used to mark places that can throw errors. The declaration of veggies cannot throw an error; only the uses of veggies can throw errors, which is why we have:

Right, that's why we should consider new decorators, like try(dtor). The notion of a destructor than can throw (if that is the model we think is best -- still very unclear from the discussion) is a fundamentally new/unprecedented notion to Swift. We shouldn't try to paper over it with existing constructs IMO.

@Douglas_Gregor

Property wrappers need to be heavily customized to get the semantics we need for child tasks.

The entire point of property wrappers is to provide open library-based extensibility for properties. Adding a few new features to them seems like an investment that will pay off many-fold into the future.

My metapoint is that this proposal is presented without alternatives - there is no exploration of the design space, and it isn't clear to us community members what attempts to leverage existing language affordances have been made. Furthermore, the design of this feature has not evolved significantly since its original pitch many months ago (even though the base language has taken significant changes) so I don't have a lot of confidence that this was "first-principled" since then.

All of the things you point at as weaknesses of property wrappers seem like things that would be better solved by making property wrappers more powerful, rather than inventing a one-off language feature that doesn't provide the library-based extensibility that advanced Swift programmers have come to love/expect.

@Douglas_Gregor

We have an established pattern for this: { ... multi-line-closure ... }()

I agree this works, but are you seriously arguing that people should use this anti-pattern? If that were better, then we should be consistent. e.g. would you argue that we should forbid braces on if statements? You could always use expressions to emulate them after all:

  if cond {
    doThing()
    otherThing()
   } () else {
     ...

instead of:

  if cond {
    doThing()
    otherThing()
  } else {

... while possible, would this make Swift a better language?

There is a simple and clear alternative on the table that would fix this for the important new language feature that this proposal is discussing. I think this affordance deserves to feel first class and build on the existing support we have for this sort of thing.

-Chris