<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">One small note on the async keyword, I would put it first unlike throws:<br />
<br />
async func myFunc() -> Type {<br />
return await typeProducer()<br />
}<br />
<br />
This improves the readability for the consumer .<br />
Also async implies throws as it denotes wrapping an await call, not sure if we need to specify it as well.<br />
<br /></div>
<div name="messageReplySection"><br />
On Aug 26, 2017, 14:59 -0400, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org>, wrote:<br />
<blockquote type="cite"><br />
<br />
<div id="AppleMailSignature">Sent from my iPhone</div>
<div><br />
On 26 Aug 2017, at 18:36, Adam Kemp via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br />
<br /></div>
<blockquote type="cite">
<div>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />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><br /></div>
<div>This isn’t an either/or proposition. We should have both, and they should work together. <br />
<br /></div>
</div>
</blockquote>
<div><br /></div>
<div>+1</div>
<br />
<blockquote type="cite">
<div>
<div>
<div id="AppleMailSignature">--
<div>Adam Kemp</div>
</div>
<div><br />
On Aug 25, 2017, at 10:08 PM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br />
<br /></div>
<blockquote type="cite">
<div>
<div dir="ltr">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" />
<div>
<div class="gmail_signature" data-smartmail="gmail_signature">  -- Howard.<br /></div>
</div>
<br />
<div class="gmail_quote">On 26 August 2017 at 10:57, Florent Vilmart via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div name="messageBodySection">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 />
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>
<div class="h5">
<div name="messageReplySection"><br />
On Aug 25, 2017, 20:50 -0400, Jonathan Hull <<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>>, wrote:<br />
<blockquote type="cite"><br />
<div>
<blockquote type="cite">
<div>On Aug 25, 2017, at 3:38 PM, Trevör Anne Denise <<a href="mailto:trevor.annedenise@icloud.com" target="_blank">trevor.annedenise@icloud.com</a>> wrote:</div>
<br class="m_7725227404022006943Apple-interchange-newline" />
<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">==============================<wbr />==============================<wbr />=</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">
<blockquote type="cite">Jonathan Hull jhull at<span class="m_7725227404022006943Apple-converted-space"> </span><a href="http://gbis.com/" target="_blank">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">
<blockquote type="cite">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">
<div></div>
<div><br /></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">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"><br /></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"><br /></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">
<div></div>
<blockquote type="cite">
<div>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><br /></div>
<div><span class="m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let a = async longCalculationA()</div>
<div><span class="m_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><span class="m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let c = async longCalculationC() //c doesn’t wait for a or b</div>
<div><span class="m_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"><br /></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">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_7725227404022006943Apple-interchange-newline" /></div>
</blockquote>
</div>
<br />
<div>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><br /></div>
<div><span class="m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let image = async downloadImage()</div>
<div><span class="m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let size = await image.size</div>
<div><br /></div>
<div>to:</div>
<div><br /></div>
<div><span class="m_7725227404022006943Apple-tab-span" style="white-space:pre-wrap"></span>let size = await downloadImage().size</div>
<div><br /></div>
<div>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><br /></div>
<div>Given that as a base, it would be trivial to create a framework offering true Futures (which allow cancelling, etc…)</div>
<div><br /></div>
<div>Thanks,</div>
<div>Jon</div>
<div><br /></div>
</blockquote>
</div>
</div>
</div>
</div>
<br />
______________________________<wbr />_________________<br />
swift-evolution mailing list<br />
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br />
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr />mailman/listinfo/swift-<wbr />evolution</a><br />
<br /></blockquote>
</div>
<br /></div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br />
<span>swift-evolution mailing list</span><br />
<span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br />
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br /></div>
</blockquote>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br />
<span>swift-evolution mailing list</span><br />
<span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br />
<span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br /></div>
</blockquote>
</blockquote>
</div>
</body>
</html>