I’m still not a fan of the API idiom of accepting a queue on which to run callbacks. There are dangers there… but maybe they’re academic.
Conversation
: I’m also a big proponent of only allowing execution to cross module boundaries on the main thread. Because expectations.
1
I’m also okay with allowing boundary crossing on “an arbitrary global concurrent queue” because you’ll have to do the same things.
1
: As long as its well-advertised. Problem is how many people assume they’re always on the main thread and blindly touch UI.
2
As an API consumer, boiler plate queue management in all callbacks hurts cleanliness and legibility - IMO.
2
Unchecked assumptions are worse than boilerplate code enforcing correctness :)
1
Replying to
The fact that these are our only two options suggests that we API authors have work to do.