<div dir="ltr">You are correct, my mistake. Example should read:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><font face="monospace, monospace">func processImageData1() -> Future<Image> {<br> return AsynchronousFuture { _ -> Image in<br> let dataResource = loadWebResource("dataprofile.txt") // dataResource and imageResource run in parallel.<br> let imageResource = loadWebResource("imagedata.dat")<br> let imageTmp = decodeImage(dataResource.get ?? Resource(path: "Default data resource or prompt user"), imageResource.get ?? Resource(path: "Default image resource or prompt user"))<br> let imageResult = dewarpAndCleanupImage(imageTmp.get ?? Image(dataPath: "Default image or prompt user", imagePath: "Default image or prompt user"))<br> return imageResult.get ?? Image(dataPath: "Default image or prompt user", imagePath: "Default image or prompt user")<br> }<br>}</font></blockquote></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 25 August 2017 at 00:25, BJ Homer <span dir="ltr"><<a href="mailto:bjhomer@gmail.com" target="_blank">bjhomer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Your <font face="Menlo">processImageData1()</font> function is not asynchronous, and does not need to return a future, because the “<font face="Menlo">.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">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><br></div><div>The point of async/await is that we can wait for the completion of those items <i>asynchronously</i>, not blocking the current thread. The control would return to the calling function before all the data was fetched.</div><div><br></div><div>-BJ</div><div><br><div><blockquote type="cite"><div>On Aug 23, 2017, at 7:35 PM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-2093663413535578341Apple-interchange-newline"><div><div dir="ltr">Hi All,<div><br></div><div>Really glad that concurrency is on the table for Swift 5.<br><div><br></div><div>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><br></div><div>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><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>func loadWebResource(_ path: String) -> Future<Resource> { ... }</div><div>func decodeImage(_ dataResource: Resource, _ imageResource: Resource) -> Future<Image> { ... }</div><div>func dewarpAndCleanupImage(_ image: Image) -> Future<Image> { ... }</div><div><br></div><div>func processImageData1() -> Future<Image> {</div><div> let dataResource = loadWebResource("dataprofile.<wbr>txt") // dataResource and imageResource run in parallel.</div><div> let imageResource = loadWebResource("imagedata.<wbr>dat")</div><div> 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> let imageResult = dewarpAndCleanupImage(<wbr>imageTmp.get ?? Image(dataPath: "Default image or prompt user", imagePath: "Default image or prompt user"))</div><div> return imageResult</div><div>}</div></blockquote><div><div><div class="m_-2093663413535578341gmail_signature"> </div><div class="m_-2093663413535578341gmail_signature">Which I would argue is actually better than the proposed async/await code because:</div><div class="m_-2093663413535578341gmail_signature"><ol><li>The code is naturally parallel, in example dataResource and imageResource are calculated in parallel. <br></li><li>The code handles errors and deadlocks by providing a default value using `??`.</li><li>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>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="m_-2093663413535578341gmail_signature">In summary, I don't think async/await carries its weight (pun intended), as it stands, compared to a library.</div><div class="m_-2093663413535578341gmail_signature"><br></div><div class="m_-2093663413535578341gmail_signature">But definitely for more Swift concurrency,</div><div class="m_-2093663413535578341gmail_signature"><br></div><div class="m_-2093663413535578341gmail_signature"> -- Howard.<br></div></div><div class="m_-2093663413535578341gmail_signature"><br></div><div class="m_-2093663413535578341gmail_signature">PS A memory model and atomic that also guaranteed volatile would really help with parallel programming!</div><div class="m_-2093663413535578341gmail_signature"><br></div><div class="m_-2093663413535578341gmail_signature">…(snip)...</div></div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div><div><div><div class="m_-2093663413535578341gmail_signature">______________________________<wbr>_________________</div></div></div></div></div>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>