<div dir="ltr">&quot;<span style="color:rgb(33,33,33);font-size:13px">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.</span>&quot;<div><br></div><div>I understand this, however if you reverse the evaluate order, in this particular problem, there&#39;s no bug.</div><div><br></div><div><div>My point is: When order is important, it will not be a new &quot;await&quot; inline that will solve. The developer will look at the &quot;await&quot; 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. </div><div><br></div><div>Actually, I think several await on the same line will only make the debugging process more difficult.<br></div><div><br></div><div>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.</div></div><div><br></div><div>&quot;<span style="color:rgb(33,33,33);font-size:13px">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.</span>&quot;</div><div><br></div><div>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.<br></div><div><br></div><div>A simple break point in this line will help!</div><div><br></div><div>&quot;<span style="color:rgb(33,33,33);font-size:13px">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.</span>&quot;</div><div><br></div><div>You only pointed  the need to returning to the right queue. No disagreement here. You can suggest other way of course. I also don&#39;t like this style too.<br></div><div><br></div><div><br></div><div><br></div><div><div class="gmail_quote"><div dir="ltr">Em ter, 12 de set de 2017 às 17:53, Adam Kemp &lt;<a href="mailto:adam.kemp@apple.com">adam.kemp@apple.com</a>&gt; escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div>On Sep 12, 2017, at 1:00 PM, Wallacy &lt;<a href="mailto:wallacyf@gmail.com" target="_blank">wallacyf@gmail.com</a>&gt; wrote:</div><div><div dir="ltr" style="font-family:Helvetica;font-size:24px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div><br></div><div><div>So, the problem is a predefined order to evaluate the values, not a &quot;second&quot; await.</div></div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>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.</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><br><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:24px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div>Like you said, the person can write the wrong code ever anyway!</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>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.</div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><br></div><blockquote type="cite"><div dir="ltr" style="font-family:Helvetica;font-size:24px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div></div><div>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.</div></div></blockquote><div><br></div><div><br></div><div>The proposal already covered this:</div><div><br></div><div><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,&quot;Liberation Mono&quot;,Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;word-wrap:normal;padding:16px;overflow:auto;line-height:1.45;background-color:rgb(246,248,250);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;color:rgb(36,41,46)">  await DispatchQueue.<span class="m_-5027774370165661090inbox-inbox-pl-smi" style="box-sizing:border-box">main</span>.<span class="m_-5027774370165661090inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">syncCoroutine</span>()</pre></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"></blockquote></div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div></div><br><div>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.</div><div><br></div><div>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.</div></div></blockquote></div></div></div>