<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Your <font face="Menlo" class="">processImageData1()</font> function is not asynchronous, and does not need to return a future, because the “<font face="Menlo" class="">.get</font>” calls are blocking; as you have implemented them, they will wait until they have a response or timeout. As a result, by the time you reach the <font face="Menlo" class="">return imageResult</font> line, you have already waited for that data (or timed out), with the current thread blocked. There is no work left to do in the Future.<div class=""><br class=""></div><div class="">The point of async/await is that we can wait for the completion of those items <i class="">asynchronously</i>, not blocking the current thread. The control would return to the calling function before all the data was fetched.</div><div class=""><br class=""></div><div class="">-BJ</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 23, 2017, at 7:35 PM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi All,<div class=""><br class=""></div><div class="">Really glad that concurrency is on the table for Swift 5.<br class=""><div class=""><br class=""></div><div class="">I am not sure if async/await are worth adding, as is, to Swift because it is just as easy to do with a library function - in the spirit of Swift 5, see `Future` library code below that you can play with and run.<div class=""><br class=""></div><div class="">If a `Future` class was added and the compiler translated 'completion-handler' code to 'future' code then the running example given in the whitepaper would become (also see the example in the code below):</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">func loadWebResource(_ path: String) -> Future<Resource> { ... }</div><div class="">func decodeImage(_ dataResource: Resource, _ imageResource: Resource) -> Future<Image> { ... }</div><div class="">func dewarpAndCleanupImage(_ image: Image) -> Future<Image> { ... }</div><div class=""><br class=""></div><div class="">func processImageData1() -> Future<Image> {</div><div class=""> let dataResource = loadWebResource("dataprofile.txt") // dataResource and imageResource run in parallel.</div><div class=""> let imageResource = loadWebResource("imagedata.dat")</div><div class=""> let imageTmp = decodeImage(dataResource.get ?? Resource(path: "Default data resource or prompt user"), imageResource.get ?? Resource(path: "Default image resource or prompt user"))</div><div class=""> let imageResult = dewarpAndCleanupImage(imageTmp.get ?? Image(dataPath: "Default image or prompt user", imagePath: "Default image or prompt user"))</div><div class=""> return imageResult</div><div class="">}</div></blockquote><div class=""><div class=""><div class="gmail_signature"> </div><div class="gmail_signature">Which I would argue is actually better than the proposed async/await code because:</div><div class="gmail_signature"><ol class=""><li class="">The code is naturally parallel, in example dataResource and imageResource are calculated in parallel. <br class=""></li><li class="">The code handles errors and deadlocks by providing a default value using `??`.</li><li class="">The code can be deadlock free or can help find deadlocks, see code below, due to having a timeout and a means of cancelling.</li><li class="">The programmer who writes the creator of the `Future` controls which queue the future executes on, I would contend that this is the best choice since the programmer knows what limitations are in the code and can change queue if the code changes in later versions. This is the same argument as encapsulation, which gives more control to the writer of a struct/class and less control to the user of the struct/class.</li></ol></div><div class="gmail_signature">In summary, I don't think async/await carries its weight (pun intended), as it stands, compared to a library.</div><div class="gmail_signature"><br class=""></div><div class="gmail_signature">But definitely for more Swift concurrency,</div><div class="gmail_signature"><br class=""></div><div class="gmail_signature"> -- Howard.<br class=""></div></div><div class="gmail_signature"><br class=""></div><div class="gmail_signature">PS A memory model and atomic that also guaranteed volatile would really help with parallel programming!</div><div class="gmail_signature"><br class=""></div><div class="gmail_signature">…(snip)...</div></div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class="gmail_signature">_______________________________________________</div></div></div></div></div>swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>