Totally agree with Adam.
> Am 13.09.2017 um 00:39 schrieb Adam Kemp via swift-evolution
> <swift-evolution@swift.org>:
>
>> On Sep 12, 2017, at 2:40 PM, Wallacy <walla...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
