Bei LiIs this modern #Swift? 
@mattiem Hope your concurrency guide can cover this with a grace solution.
Matt Massicotte@libei There is a lot going on here. I will say that in general, I do not like using async stuff with notifications. Are you sure you want to do that?
deinit is a known problem but today, I have no solutions
Lucka
inket 
@libei Remember when they said async-await gets rid of callback hell?
@inket Now we got Task and MainActor hell.
Ed@libei Not sure if it matters here, but there’s no guarantee for /when/ the body of the loop will be called.
Imagine wrapping everything in DispatchQueue.main.async {} <- you may have subtle UI issues if you’re reacting to notifications async from the context where they were posted.
(Maybe in this case it’s fine?!)
@edwellbrook setUpNotificationTask() is implicitly protected by MainActor, so the Task will inherit MainActor and (I assume) the body of loops will be executed on MainActor/thread.
But I don't 100% sure about how notifications(named:) works, so perhaps I'm already in a situation, like DispatchQueue.main.async {}, reacting to notifications asynchronously. 
Honestly Swift Concurrency is really painful. 😇
@libei Yes, this is all executed on the main actor (the “where”), but because there’s a Task + await, there’s no guaruntee on the “when”. So treat this like main.async {}.
If you care about reacting to the notif “inline” from where it was posted, you probably want to use the addObserver method. You may/may not need to care about that here!
@edwellbrook Guess we have to use the old good target action way.
Luke Van In@libei Anyone can create spaghetti in any language - some languages just make it a little easier.
Kyle Bashour