> On 28 Aug 2017, at 22: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.
I understand the value you perceive but I think that the try and await solution of applying to the whole statement is a good compromise to greatly improve readability at the expense of a little lost information. >> 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
