<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=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 27.08.2017 um 17:48 schrieb David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 27 Aug 2017, at 06:09, Wallacy 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=""><div class=""><div class="">Chris's proposal is very explicit about the advantages of the async/await over the Future/Task, we don't need to rephrase here. The most obvious advantage of course is because "await" does not block the execution (Future.get() does).<br class=""></div></div><div class=""><br class=""></div><div class="">And the whole proposal about async/await/actors is very, very good! Except... When talks about the need to implement Future class as part of the standard library! Like said on async/await proposal, the "Future" needs another proposal to adress the details. But describ only one "good" feature of the "Future" over the async/await: </div><div class=""><br class=""></div><div class="">...</div><div class="">"allow parallel execution, by moving await from the call to the result when it is needed, and wrapping the parallel calls in individual Future objects"</div><div class="">...</div><div class=""><br class=""></div><div class="">This is very important thing! And if not addressed by the language or the standlibrary, third party libraries will. But also, has few downsides. The proposal already covered this:<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I agree that having a way to “await multiple async results at the same time” seems like something very important. And both JavaScript and C# get those because async/await is based on Futures/Promises. I’m okay with the current direction of the async/await proposal in Swift (i.e., not built on top of Promises), but we need to a way to be on feature parity with those other languages (without a third-party library) if we want Swift’s async/await to be truly useful.</div></div></div></div></blockquote><div><br class=""></div><div><br class=""></div>I like the `Futureless` async/await proposal too and think that using `async` in two different ways as proposed by some could be confusing.</div><div><br class=""></div><div>I think providing some simple `combinators` atop of coroutine based async/await would be very versatile:</div><div><br class=""></div><div>e.g providing a `parallel` combinator would allow to `await` multiple async tasks:</div><div><br class=""></div><div>```</div><div>let (userData, image) = await parallel(</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>await downloadUserData(),</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>await downloadImage()</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> )</div><div>```</div><div><br class=""></div><div>`parallel()` could work like this:</div><div><br class=""></div><div>```</div><div>func parallel<T, U>(_ t: @autoclosure () async throws -> T, _ u: @autoclosure () async throws -> U) async rethrows -> (T, U) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>// implementation left as an exercise ;-)</div><div>}</div><div><br class=""></div><div>The method could also take some additional parameters to allow specification of timeouts etc.</div><div><br class=""></div><div>You could also define some infix operators (like `<||>`) so that above would become even simpler:</div><div><br class=""></div><div>```</div><div>let (userData, image) = await downloadUserData() <||> await downloadImage()</div><div>```</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">...<br class="">"A Future type designed for Swift today would need to be a class, and therefore need to guard against potentially multithreaded access, races to fulfill or attempts to fulfill multiple times, and potentially unbounded queueing of awaiting coroutines on the shared future;"<br class="">"The proposed design eliminates the problem of calling an API (without knowing it is async) and getting a Future<T> back instead of the expected T result type."<br class="">"By encoding async as a first-class part of function types, closure literals can also be transparently async by contextual type inference. "<br class="">"Requiring a future object to be instantiated at every await point adds overhead."<br class="">etc...<br class="">...<br class=""><div class=""><br class=""></div><div class="">So... My proposal is: Extend async/await functionality to close the gap needed to allow parallel execution.</div><div class=""><br class=""></div><div class="">Something like that: (using the same exemple as before)</div><div class=""><br class=""></div><div class=""><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)" class=""><span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="inbox-inbox-pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">downloadUserData</span>() async <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">-></span> UserData { <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">...</span> }
<span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="inbox-inbox-pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">downloadImage</span>() async <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">-></span> UIImage { <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">...</span> }
<span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="inbox-inbox-pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">someAsyncFunc</span>() async <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">-></span> User {
<span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">var</span> userData <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> async <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">downloadUserData</span>() <span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> userData is of type `async UserData` as we used async</span>
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">var</span> image <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> async <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">downloadImage</span>() <span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> image is of type `async UserData`</span>
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">return</span> await <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">User</span>(userData, image) <span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> needs to call await to use any `async T`</span>
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span>}</pre></div><div class=""><br class=""></div><div class=""><span style="background-color:rgb(246,248,250);color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px" class="">await </span> still does not block execution, the lifetime of `async T` is very previsible, (Future<T> can be stored, passed around, etc.), and any "Future Like" type can be implement on the top of this!</div><div class=""><br class=""></div><div class=""><span style="background-color:rgb(246,248,250);color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px" class="">async</span> at call side needs to replace <span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;background-color:rgb(246,248,250)" class="">beginAsync</span>? Not necessarily. We may consider that calling anything with 'async' at startup implies <span style="background-color:rgb(246,248,250);color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px" class="">beginAsync</span> with return T and can be 'awaited', suspended, etc. But its not the main use for async at call side in my opinion. The lifetime of this call can handled in the same way as beginAsync.<br class=""></div><div class=""><br class=""></div><div class=""><span style="background-color:rgb(246,248,250);color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px" class="">async</span> at call side created another type? No! Its the point here! This "virtual type" only need to exists on the context of the caller, and can be used by the compiler to enforce the "await" at some point.<br class=""></div><div class=""><br class=""></div><div class="">I can "re<span style="background-color:rgb(246,248,250);color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px" class="">async"</span>any call? It's interesting, I think it's worth to be considered.</div><div class=""><br class=""></div><div class=""><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)" class=""><span class="inbox-inbox-inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="inbox-inbox-inbox-inbox-pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">someAsyncFunc</span>() async <span class="inbox-inbox-inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">-></span> User {
<span class="inbox-inbox-inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">var</span> userData <span class="inbox-inbox-inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> async <span class="inbox-inbox-inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">downloadUserData</span>()
<span class="inbox-inbox-inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> <span class="inbox-inbox-inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">var</span> image <span class="inbox-inbox-inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> async <span class="inbox-inbox-inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">downloadImage</span>()
<span class="inbox-inbox-inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> <span class="inbox-inbox-inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">return</span> async <span class="inbox-inbox-inbox-inbox-pl-c1" style="font-size:13.6px;box-sizing:border-box;color:rgb(0,92,197)">User</span><span style="font-size:13.6px" class="">(userData, image) </span><span class="inbox-inbox-inbox-inbox-pl-c" style="font-size:13.6px;box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-inbox-inbox-pl-c" style="box-sizing:border-box">//</span> actually return () </span>async ->{ <span style="font-size:13.6px" class="">await </span><span class="inbox-inbox-inbox-inbox-pl-c1" style="font-size:13.6px;box-sizing:border-box;color:rgb(0,92,197)">User</span><span style="font-size:13.6px" class="">(userData, image) </span><span style="font-size:13.6px" class="">} or similar.</span></pre><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)" class="">}</pre></div><div class=""><br class=""></div><div class="">Can i suspend any calls? Maybe in this way:</div><div class=""><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)" class=""><span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">let</span> imageResource <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">try</span> async <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">loadWebResource</span>(<span class="inbox-inbox-pl-s" style="box-sizing:border-box;color:rgb(3,47,98)"><span class="inbox-inbox-pl-pds" style="box-sizing:border-box">"</span>imagedata.dat<span class="inbox-inbox-pl-pds" style="box-sizing:border-box">"</span></span>)
<span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">do</span> {
<span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">let</span> imageTmp <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">=</span> <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">try</span> await <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">decodeImage</span>(dataResource, imageResource)
} <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">catch</span> <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">_</span> <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">as</span> InvalidResourc {
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> Does not need to finish the imageResource await.</span>
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> await <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">suspendAsync</span>(imageResource) <span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> just a exemple...</span>
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> }<span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">catch</span> <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">_</span> <span class="inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">as</span> CorruptedImage {
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> Give up hope now.</span>
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> await <span class="inbox-inbox-pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">abandon</span>() <span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="inbox-inbox-pl-c" style="box-sizing:border-box">//</span> like before</span>
<span class="inbox-inbox-pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span> }</pre></div><div class=""><br class=""></div><div class=""><div class="">Also, i dont like the idea of suspendAsync be a standlibrary function! Maybe a keyword modifier? (await suspendAsync _ / await suspendAsync abc )</div></div><div class=""><br class=""></div><div class="">Anyway... I do not want to be adding too many ideas at the same time, there are several ideas around "async". My point is just to enable parallel execution without the introduction of another type. Whatever comes next is profit!</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="gmail_quote"><div dir="ltr" class="">Em sáb, 26 de ago de 2017 às 14:37, Adam Kemp via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> escreveu:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="">C# had futures (in the form of the Task Parallel Library) before it had async/await. If you could see how much async/await has revolutionized C# programming you would not be making this argument. It is night and day. Asynchronous code is so much clearer with this feature than without. You can write code the is simpler and safer at the same time.<div class=""><br class=""></div><div class="">This isn’t an either/or proposition. We should have both, and they should work together. <br class=""><br class=""><div id="m_-8999947934020771256AppleMailSignature" class="">--<div class="">Adam Kemp</div></div></div></div><div dir="auto" class=""><div class=""><div class=""><br class="">On Aug 25, 2017, at 10:08 PM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">I just don't see that async/await adds enough to warrant a language change. You can write Future on top of GCD and a future type can do more, like having a cancel, having a timeout, and giving control over what thread is used.</div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="m_-8999947934020771256gmail_signature" data-smartmail="gmail_signature"> -- Howard.<br class=""></div></div>
<br class=""><div class="gmail_quote">On 26 August 2017 at 10:57, Florent Vilmart via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
<div name="messageBodySection" class="">Isn’t async / await an evolution over Promises / Tasks / Futures? AFAIK in JS, any function that returns a promise can be ‘await’ upon, and underneath, to be able to await, a function has to return a promise. Marking a function async in JS, tells the consumer that some await are going on inside, and it’s impossible to use await outside of an async marked function. I believe swift is going that direction too. Futures / Promises are the foundation on which async / await can truly express as it formalizes the boxing of the result types.<br class="">
What would be interesting is async being based on a protocol FutureType for example, so you can bring your own library and yet, leverage async / await</div><div class=""><div class="m_-8999947934020771256h5">
<div name="messageReplySection" class=""><br class="">
On Aug 25, 2017, 20:50 -0400, Jonathan Hull <<a href="mailto:jhull@gbis.com" target="_blank" class="">jhull@gbis.com</a>>, wrote:<br class="">
<blockquote type="cite" class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise <<a href="mailto:trevor.annedenise@icloud.com" target="_blank" class="">trevor.annedenise@icloud.com</a>> wrote:</div>
<br class="m_-8999947934020771256m_7725227404022006943Apple-interchange-newline">
<div class="">
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">=============================================================</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<blockquote type="cite" class="">Jonathan Hull jhull at<span class="m_-8999947934020771256m_7725227404022006943Apple-converted-space"> </span><a href="http://gbis.com/" target="_blank" class="">gbis.com</a> </blockquote>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<blockquote type="cite" class="">This looks somewhat similar to a future, but you can’t interact with it as a separate type of object. The value above is just a UIImage, but with a compiler flag/annotation that forces me to call await on it before it can be accessed/used. The compiler has a lot more freedom to optimize/reorganize things behind the scenes, because it doesn’t necessarily need to make an intermediate object.</blockquote>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class=""></div>
<div class=""><br class=""></div>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">As for the message of Wallacy I'd be interested the pros and cons of hiding the implementation details ! :)</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">
<div class=""></div>
<blockquote type="cite" class="">
<div class="">To prove (or potentially disprove) my assertion that this is not just sugar, how would you accomplish the following under the current proposal?</div>
<div class=""><br class=""></div>
<div class=""><span class="m_-8999947934020771256m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let a = async longCalculationA()</div>
<div class=""><span class="m_-8999947934020771256m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let b = async longCalculationB() //b doesn’t wait for a to complete before starting</div>
<div class=""><span class="m_-8999947934020771256m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let c = async longCalculationC() //c doesn’t wait for a or b</div>
<div class=""><span class="m_-8999947934020771256m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let result = await combineCalculations(a: a, b: b, c: c) //waits until a, b, and c are all available</div>
</blockquote>
</div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Would this be implemented differently than with Futures? I don't have much experience with concurrency, but I don't see how this would be handled differently than by using Futures, internally ? (at least for this case)</div>
<br class="m_-8999947934020771256m_7725227404022006943Apple-interchange-newline"></div>
</blockquote>
</div>
<br class="">
<div class="">It looks/behaves very similar to futures, but would potentially be implemented differently. The main difference is that the resulting type is actually the desired type (instead of Future<Type>) with a compiler flag saying that it needs to call await to be used. Behind the scenes, this could be implemented as some sort of future, but the compiler has a lot more freedom to rearrange things to be much more efficient because there is no affordance for the user to introspect or cancel. So for example, it might actually change:</div>
<div class=""><br class=""></div>
<div class=""><span class="m_-8999947934020771256m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let image = async downloadImage()</div>
<div class=""><span class="m_-8999947934020771256m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let size = await image.size</div>
<div class=""><br class=""></div>
<div class="">to:</div>
<div class=""><br class=""></div>
<div class=""><span class="m_-8999947934020771256m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let size = await downloadImage().size</div>
<div class=""><br class=""></div>
<div class="">This would depend on the other code around it, but the compiler has much more freedom to avoid creating intermediate values, or even to create different types of intermediate values which are more efficient for the situation at hand.</div>
<div class=""><br class=""></div>
<div class="">Given that as a base, it would be trivial to create a framework offering true Futures (which allow cancelling, etc…)</div>
<div class=""><br class=""></div>
<div class="">Thanks,</div>
<div class="">Jon</div>
<div class=""><br class=""></div>
</blockquote>
</div>
</div></div></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">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=""></body></html>