> On Sep 12, 2017, at 1:00 PM, Wallacy <walla...@gmail.com> wrote:
>
> So, the problem is a predefined order to evaluate the values, not a "second"
> await.
No, the order of execution is well-defined. The problem isn’t in which order
the arguments are executed. The problem is when that evaluation happens with
respect to when we return to the run loop. That’s an entirely new problem with
async/await. In Swift today it is not possible to write code that returns to
the run loop in between evaluation of arguments.
> Like you said, the person can write the wrong code ever anyway!
True. There are many ways to write bugs. The question is whether the language
makes those bugs easier to spot or does it obfuscate them? Making await
explicit every time makes this bug easier to see. If I were doing a code review
I could spot that bug. Without the explicit await it would be much harder to
spot by just reading the code. It’s not clear whether it’s even a bug unless
you already know that “processImage” is an async function.
> This example also shows once again the importance of returning to the right
> queue. If the “await downloadImage” continues on some other queue then you
> would be using UIKit on a background thread, which is not allowed. It seems
> like we’re starting to see some convergence on this idea, which I’m glad to
> see.
>
>
> The proposal already covered this:
>
> await DispatchQueue.main.syncCoroutine()
As I’ve mentioned before, the proposal is a proposal. This is the discussion of
the proposal. I think it’s reasonable for us to disagree with the proposal,
especially if we can explain why we think it should change.
As someone who has used C#’s async/await feature (for iOS apps, even) I know
first-hand how useful this feature can be (as well as its pitfalls). I’m
excited about the prospect of using it in Swift. That’s why I want it to be as
good as it can be. As proposed I don’t think it is as good as it can be. That’s
why I’m participating in this discussion.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
