[swift-evolution] await keyword "scope"

[Wallacy]

"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."

I understand this, however if you reverse the evaluate order, in this
particular problem, there's no bug.

My point is: When order is important, it will not be a new "await" inline
that will solve. The developer will look at the "await" and may still not
realize that the root of the bug was because `resizeSwitchIsOn` was
obtained before. Another `await` inline will not make clear this problem,
maybe will for you but not for everybody.

Actually, I think several await on the same line will only make the
debugging process more difficult.

There is no proof that this will help the developer for cases like that.
Most likely it will put the break point inside processImage and see what
values were loaded. And even at call side the debugger will tell the
expected values.

"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.
"

I really do not know if this is a really common problem. In practice I
believe that anyone who is observing the code will know, unless it is the
first time that he is doing maintenance. And if this is the case, another
await probably will not help too.

A simple break point in this line will help!

"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."

You only pointed  the need to returning to the right queue. No disagreement
here. You can suggest other way of course. I also don't like this style too.



Em ter, 12 de set de 2017 às 17:53, Adam Kemp <adam.kemp at apple.com>
escreveu:

>
> On Sep 12, 2017, at 1:00 PM, Wallacy <wallacyf at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170912/b506be07/attachment.html>