[swift-evolution] [Concurrency] async/await + actors

[Yuta Koshizawa]

>> On Aug 21, 2017, at 1:56 PM, John McCall <rjmccall at apple.com> wrote:
>>
>> Personally, I think these sources of confusion are a good reason to keep the feature separate.
>>
>> The idea of using await! to block a thread is interesting but, as you say, does not fit with the general meaning of ! for logic errors.  I think it's fine to just have an API to block waiting for an async operation, and we can choose the name carefully to call out the danger of deadlocks.
>>
>> John.
>
> 2017-08-22 5:08 GMT+09:00 Karim Nassar <karim at karimnassar.com>:
>
> Thought about it in more depth, and I’m now firmly in the camp of: ‘throws’/‘try' and ‘async’/‘await' should be orthogonal features. I think the slight call-site reduction in typed characters ('try await’ vs ‘await’) is heavily outweighed by the loss of clarity on all the edge cases.
>
> —Karim


I agree.

1. `async(nonthrowing)` and `async` as a subtype of `throws` can be an
obstacle when we want to add the third effect following `throws` and
`async` though I think `async(nonthrowing)` is an interesting idea.
Assuming that the new effect is named `foos`, we may want
`async(nonfooing)` or to make `async` be a subtype of `foos`. But it
is hard because they are destructive. We need to modify all code which
uses `async`. However, it is inconsistent with `throws` to give up
them and make `foos` orthogonal to `async`.

2. It is also true for `throws`. If we had introduced `async/await`
before `throws/try` were introduced, it would be hard to introduce
`async(nonthrowing)`  or `async` as a subtype of `throws` because they
are destructive. (Although `async/await` without `throws/try` seems
impractical, it is not impossible by something like `func bar() async
-> Result<Foo>`)

So I think `async` and `throws` are essentially orthogonal, and just
factually used together in most cases. I guess choosing the essential
one will keep the language simpler and prevent unexpected problems in
the future.

--
Yuta