First of all, thank you to everyone for reacting ! :)
Taking the messages in chronological order :
> Wallacy <[email protected]>
> Interesting, its syntax seems to improve the "fire and forget" issue.
>
> @IBAction func buttonClicked() {
> async downloadAndUpdateImageView()
> }
While this could be nice it would indeed not be needed in this case @IBAction
methods were async as Chris Lattner says.
> func SomethingUsingUser() -> Void {
> var user = await getUser() //Only here
> printf(user.age > 21 ? "Let's Drink" : "See you later!")
I don't have a lot of experience with async await syntaxes, but if I understand
correctly the proposal and the way async/await works, doing that inside of a
non-async function would be problematic as this would block the thread and
wouldn't clearly show that calling your function would be blocking (being
forced to marked a function as async and the imposed language syntax at call
site fixes this issue).
That's why I only proposed "async outside of await" and not "await outside of
async", because async outside of await would still enable the compiler to
prevent issues like the aforementioned one thanks to a Future like behaviour.
=============================================================
> Chris Lattner <[email protected]>
>
> Yes, it is entirely possible that we will want to provide more syntactic
> sugar than the proposal suggests: the proposal is intentionally designed to
> be minimal, so we can get it in place, get experience using it, then decide
> whether any specific syntactic pain point is significant enough to be worth
> adding additional sugar/complexity.
>
> As has been mentioned in other threads, the hope is that “beginAsync” is
> actually extremely rare in practice. If that is the case, there is little
> point to sugaring it.
>
> -Chris
The second part of my proposition is indeed more syntactic sugar if beginAsync
ends up being rarely used in practice, but about the first part of my
explanation (using async inside of async functions to provide a future like
syntax), would it enable to both to drastically reduce the syntactic complexity
of async/await and to hide away implementation giving more freedom for future
Swift releases as Wallacy and Jonathan Hull suggested?
Thank you ! :)
=============================================================
> Wallacy <[email protected] <mailto:[email protected]>>
> Using only async/await is pretty easy to learn and teach.
> And after that, "Future" can be implement in any way because will not be a
> public API anymore (I do not know, but there may also be some opportunities
> for optimization as well), and we only need to care about when we need to
> "keep the reference" from some async call.
>
> And possibly, they will not need to create any Future type! The variable
> type will be "async User" as long as it is not "unwrapped". (
> suspend/defer/abandon still possible)
Using async at call site would indeed (in my opinion) make async/await easier
to learn (especially given the parallel with optional unwrapping and
similarities with other behaviours of Swift, including possible async vars of
Actors maybe?).
I'd be interested to know what would be the ramifications of promoting async at
type level as you propose, what would be the pros and cons of such an approach
? I'd be interested to get other opinions about it ! :)
In my first idea async at call site would be synthesising a Future<T> just as
T? synthesises Optional<T>, but I'd be interested to know too if hiding
implementation details would have any advantages for the future of Swift ?
Making things more flexible maybe?
=============================================================
> Jonathan Hull jhull at gbis.com
> 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.
As for the message of Wallacy I'd be interested the pros and cons of hiding the
implementation details ! :)
> To prove (or potentially disprove) my assertion that this is not just sugar,
> how would you accomplish the following under the current proposal?
>
> let a = async longCalculationA()
> let b = async longCalculationB() //b doesn’t wait for a to complete
> before starting
> let c = async longCalculationC() //c doesn’t wait for a or b
> let result = await combineCalculations(a: a, b: b, c: c) //waits until
> a, b, and c are all available
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)
=============================================================
> Florent Vilmart florent at flovilmart.com
> Probably with:
>
> let a = longCalculationA()
> let b = longCalculationB() //b doesn’t wait for a to complete before starting
> let c = longCalculationC() //c doesn’t wait for a or b
> let (aResult, bResult, cResult) = await Future.collect(a, b, c) //waits until
> a, b, and c are all available
This isn't possible with the proposed async/await syntax, is it ?
Thank you everyone !! :)_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
