Some comments after watching "Swift concurrency: Update a sample app".

await updateUI()
continueWork()

is *not* equivalent to

DispatchQueue.main.async { updateUI() }
continueWork()

"await" means continueWork() will only execute after updateUI() is done.
The presenter says a function with a defaulted empty completion handler is equivalent to an async function with discardable result. Not really.

await updateUI()
continueWork()

is *not* equivalent to

updateUI(completionHandler: { })
continueWork()

Same reason.
I'm also quite confused with the presenter removing the background dispatch queue and not explaining how save() and load() are now executing in the background. The actual data load and save operations are no async themselves so is the code really executing on a background thread?
It was my understanding that actors do not provide concurrency themselves and might even execute synchronously if they are not busy. In which case this new code would really not work as expected. Though I'm waiting for the behind the scenes session to find out more about this.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Thomas

Thomas Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @tclementdev

1 Jun
So... Swift actors are coming next week and I feel obligated to remind everyone that they're probably not the right tool for the job.

Thread 👇
Actors have had some success in the cloud/server space which makes sense there because actors are distributed and messaged asynchronously across the network. This however does not seem particularly relevant to mobile/desktop apps where there are very good reasons to not go async.
Async programming is hell. Because it causes pieces of code to be executed at some later time, every await needs to be carefully considered in ways that just weren't needed before. Executions might happen during the awaits and cause all sorts of unexpected situations.
Read 8 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(