[swift-evolution] New async keyword usage

Howard Lovatt howard.lovatt at gmail.com
Sun Aug 27 18:13:42 CDT 2017


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.


On Sat, 26 Aug 2017 at 7:14 am, Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> I actually *really* 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...
>
> 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:
>
> var image = async downloadImage()  //Image is type UIImage
> //Do something else here
> let size = await image.size //The compiler forces me to call await before
> I can actually use the value
>
> 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.
>
> 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.
>
> Thanks,
> Jon
>
>
> On Aug 24, 2017, at 4:40 AM, Trevör ANNE DENISE via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello Swift community,
>
> I was really interested by the recent* Task-based concurrency manifesto*
>  and *Concrete proposal for async semantics in Swift.*
>
> 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:
>
> https://github.com/adtrevor/Swift-ideas/blob/master/New%20async%20keyword%20usage.md
>
> Would such a syntax make any sense?
>
> Thank you ! :)
>
>
> Trevör
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170827/d40d2e9a/attachment.html>


More information about the swift-evolution mailing list