RunLoop.main or DispatchQueue.main when using Combine scheduler?

So I have a conjecture on why the 'serial' vs 'concurrent' issue isn't enforced.
I had a similar issue crop up when I built FutureKit.

There isn't anything 'illegal' about dispatching into a concurrent DispatchQueue. The problem is that any 'later' blocks are no longer guaranteed to arrive in the same order..

For example:

    methodReturningPublisher()
       .receive(on: concurrentQueue)
       .map { "\($0)" }
       .sink { value in print(value) }

It's possible for two events to be sent from the publisher, but for them to printed out-of-order. It could even be that each 'print' operation in the sink could be executing in different threads, meaning the 'sink' code better be thread-safe.

I can imagine a case where the 'sink' is just performing some work on a queue of work items, and there is a performance improvement allowing the sink to run concurrent/multithreaded, and you don't care if sink fires 'out of order'. But it's a rare case for most Publishers, and a definite no-no for publishers used to bind to Views.

2 Likes