[swift-evolution] await keyword "scope"

Wallacy wallacyf at gmail.com
Mon Aug 28 15:16:40 CDT 2017

"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170828/22622ca7/attachment.html>

More information about the swift-evolution mailing list