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 < [email protected]> 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 < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -- Howard.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
