Interesting, its syntax seems to improve the "fire and forget" issue.
@IBAction func buttonClicked() { async downloadAndUpdateImageView() } In this case, the return Future<void> also does not need to be produced as one of the compiler optimization. Also, func someAsyncFunc() async -> User { var userData = async downloadUserData() // userData is of type Future<UserData> as we used async var image = async downloadImage() // Equivalentely, image is of type Future<UIImage> return await User(userData, image) // Await is somehow "unwarping" the futures back into UserData and UIImage} Makes sense to me, its pretty clear that downloadUserData and downloadImage can be run in parallel, and the "sync point" is the only point when you need the actual value. What made me curious about this pattern is to do something like that: func getUser() async -> User { var userData = async downloadUserData() var image = async downloadImage() return async User(userData, image)}func SomethingUsingUser() -> Void { var user = await getUser() //Only here printf(user.age > 21 ? "Let's Drink" : "See you later!") }// ORfunc Something2UsingUser() -> Void { var user = async getUser() var ageToDrink = getDrinkAge(); printf(user.get().age > ageToDrink ? "Let's Drink" : "See you later!") }// ORfunc Something2UsingUser() -> Void { var user = async getUser() var ageToDrink = async getDrinkAge(); printf(await user.age > ageToDrink ? "Lets Drink" : "See you latter!") // i dont know if this make sense}// OR maybe continue the processfunc CanDrink() -> async bool { var user = async getUser() return async ()=>{ user.get().age > 21 } // Or other way to pass a future computation.} But the bast part is enable this: func CanDrink() -> bool { var user = async getUser() var isOpenToDrink = barIsOpen() return isOpenToDrink ? (user.get().age > 21) : false // if bar is not open, we dont need to evaluate user, and the task can be suspended somehow.} Em qui, 24 de ago de 2017 às 08:40, Trevör ANNE DENISE via swift-evolution < swift-evolution@swift.org> escreveu: > 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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution