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@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 <walla...@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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution