>> On Aug 21, 2017, at 1:56 PM, John McCall <rjmcc...@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 <ka...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution