[swift-evolution] await keyword "scope"

[Xiaodi Wu]

I'm not convinced by this example. If webProfilePath and imagePath are
mutable, then the expression you wrote is extremely difficult to reason
about even without any async/await. I fail to see how three awaits are
better than one in helping out the situation.
On Mon, Aug 28, 2017 at 15:37 Adam Kemp via swift-evolution <
swift-evolution at swift.org> wrote:

> I explained what the value is already. It identifies clearly in your code
> where the suspension points are. Each place you see “await” would mark a
> location where your code may yield and allow other things to happen. Those
> are points where state could change unexpectedly. It’s important for
> someone writing asynchronous code to understand where those locations are.
> It’s difficult to reason about your code without that knowledge.
>
> On Aug 28, 2017, at 1:16 PM, Wallacy <wallacyf at gmail.com> wrote:
>
>
> "Try" does the same, but I do not know anyone who prefers to repeat the
> same keyword several times.
>
> return try func0(try func1(), try func2())
>
> I do not think there's any value in knowing how many interim steps also
> need "await" ... In practice, you have to wait for everyone anyway.
>
>
>
> Em seg, 28 de ago de 2017 às 17:09, Adam Kemp via swift-evolution <
> swift-evolution at swift.org> escreveu:
>
>> I decided to split this out to its own thread because it seems orthogonal
>> to other issues being discussed.
>>
>> When I read this line from the proposal:
>>
>> await decodeImage(dataResource.get(), imageResource.get())
>>
>>
>> It’s not clear to me where the asynchronous call is. There are three
>> function calls on that line. Which ones might actually suspend? You can’t
>> tell by looking at it because there’s only one await keyword (the answer is
>> all 3).
>>
>> I’m not a fan of the ambiguity of applying the await keyword to an entire
>> statement. I know some people think this is a good thing, but to me it’s
>> just obfuscating important information.
>>
>> Further, if you’re going beyond a single expression then why you would
>> stop at the statement level? Why not make it apply to the whole block or
>> even a whole function? Why require the keyword at all? It doesn’t appear to
>> be adding any value if it doesn’t specify exactly where the suspension
>> point is. “Somewhere on this line” can get rather vague.
>>
>> async/await can be a huge win for clarity, but it also comes with the
>> downside of having to think a bit more about what can happen at these
>> suspension points. I feel like it should be a goal to make it very clear
>> where those suspension points are so that we can more easily reason about
>> them. That’s why I prefer restricting it to apply to a single expression.
>> It’s very clear where the function gets suspended, which means it’s clearer
>> where you need to be concerned about things possibly happening in between
>> your code. Consider this, for example:
>>
>>
>> await decodeImage(loadWebResource(self.webProfilePath), loadWebResource(self.imagePath))
>>
>>
>> If webProfilePath and imagePath are vars then they could change in
>> between those two calls. If you can’t see that these calls are suspending
>> then you might not know to cache them up-front to ensure consistency:
>>
>> let webProfilePath = self.webProfilePath
>> let imagePath = self.imagePath
>>
>> await decodeImage(await loadWebResource(webProfilePath), await
>> loadWebResource(imagePath))
>>
>>
>> I think a general guideline we should use when considering how this
>> feature should work is to ask whether it makes bugs more likely or less
>> likely. The goal should be to reduce bugs while simplifying code. If we
>> simplify the code to the point where we’re making some bugs too subtle then
>> we may be doing more harm than good.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170829/144bc8e6/attachment.html>