<div><div dir="auto">My experience with fire and forget without any control or error detection is that it looks great in small examples but is inadequate in ‘real’ applications, it is highly deadlock prone! I think the minimum you need is timeout to break deadlocks, control over the thread running the code, cancel to eliminate hierarchies of background tasks when the top level is cancelled (e.g. by user), and status to help debugging. </div><div dir="auto"><br></div><br><div class="gmail_quote"><div>On Sat, 26 Aug 2017 at 7:14 am, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I actually <b><i>really</i></b> like the idea of using ‘async' to start a computation in a non-blocking way. It is extremely common in real-world code to want to start a few computations/downloads at once in the background and then use the results together...<div><br></div><div>I think full-fledged futures could be a framework thing added on top, but what I would really love to see at the language level is that using ‘async’ just allows you to defer calling ‘await’. That is, you could get a value back from something called with async, but you would be forced to await that value before it could be used:</div><div><br></div><div><span class="m_-263642736433602412Apple-tab-span" style="white-space:pre-wrap"> </span>var image = async downloadImage() //Image is type UIImage</div><div><span class="m_-263642736433602412Apple-tab-span" style="white-space:pre-wrap"> </span>//Do something else here</div><div><span class="m_-263642736433602412Apple-tab-span" style="white-space:pre-wrap"> </span>let size = await image.size //The compiler forces me to call await before I can actually use the value</div><div><div><div><br></div><div>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.</div><div><br></div><div>I don’t think this is just sugar. It adds expressivity and control for a set of very common use-cases which aren’t fully supported by await alone.</div><div><br></div><div>Thanks,</div><div>Jon</div><div><br></div><div><br><div><blockquote type="cite"></blockquote></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><blockquote type="cite"><div>On Aug 24, 2017, at 4:40 AM, Trevör ANNE DENISE via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-263642736433602412Apple-interchange-newline"></blockquote></div></div></div></div></div><div style="word-wrap:break-word"><div><div><div><div><blockquote type="cite"><div><div style="word-wrap:break-word">Hello Swift community,<div><br></div><div>I was really interested by the recent<i> Task-based concurrency manifesto</i> and <i>Concrete proposal for async semantics in Swift.</i></div><div><i><br></i></div><div>Looking at beginAsync() and Futures, I had an idea for a new syntax based on the `async` keyword, I'd love to hear your feedback about this idea:</div><div><a href="https://github.com/adtrevor/Swift-ideas/blob/master/New%20async%20keyword%20usage.md" target="_blank">https://github.com/adtrevor/Swift-ideas/blob/master/New%20async%20keyword%20usage.md</a></div><div><br></div><div>Would such a syntax make any sense?</div><div><br></div><div>Thank you ! :)</div><div><br></div><div><br></div><div>Trevör</div></div>_______________________________________________<br>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/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></div></div></div>_______________________________________________<br>
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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">-- Howard.</div>