[swift-evolution] await keyword "scope"

[Thorsten Seitz]

Totally agree with Adam.

> Am 13.09.2017 um 00:39 schrieb Adam Kemp via swift-evolution <swift-evolution at swift.org>:
> 
>> On Sep 12, 2017, at 2:40 PM, Wallacy <wallacyf at gmail.com> wrote:
>> 
>> "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.
> 
> I’m not sure I understand what you mean by this. We can’t reverse the evaluation order. It’s defined by the language.
> 
> Maybe you meant if the arguments themselves were ordered the other way. That would “fix” the bug, but the point of the example isn’t “show me how to fix this bug”. The point is that “given only this one line of code you can’t tell me whether the switch’s property is read before returning to the run loop or after”. There’s not enough information in that line of code itself to determine whether that’s a bug.
> 
> On the other hand, with an extra “await” I could tell you without looking at any other code that there is a bug on that line. It’s a difference in clarity.

I, too, think that this is important (and different from the case with `try`).


> Will it prevent all bugs like this from happening? Of course not. That’s not the point. The point is that by making the code clearer we can make it actually possible to look at the code and reason about it in isolation. We still have to understand the idea that the switch should be read before returning to the run loop, and we still have to actually write the code such that it does that. But the added clarity of an explicit await gives us enough information to know where that read needs to be. That’s valuable not only to the person writing the code, but to someone reviewing the code as well.
> 
>> Actually, I think several await on the same line will only make the debugging process more difficult.
> 
> How so? It would literally compile to the same code so I’m not sure how the debugger would be affected.
> 
>> 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.
> 
> Again, as someone who has actually used async/await in practice in shipping code I am telling you that this is a common problem, and it does benefit someone reading that code. This isn’t speculation. This is experience.
> 
>> A simple break point in this line will help!
> 
> I shouldn’t have to run code in a debugger to be able to spot this bug. 

Totally agree with that, especially in a language like Swift with a strong type system.

-Thorsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170913/204e4ecb/attachment.html>