On Friday, 23 July 2021 08:33:33 PDT Matthew Woehlke via Std-Proposals wrote:
> Sure, in Qt, most slots *are* executed synchronous. I don't believe it's
> the case however that most slots would work incorrectly if they
> *weren't* dispatched synchronously. That's sort of the whole concept
> behind event-driven programming.

That's because Qt attempts to go the extra mile and make it easy to do what
you may have wanted to do, even if that incurs an extra penalty for everyone
else (so long as it's not too much).

For the C++ standard, I don't think we want that (don't pay for what you don't
use). For the standard, I'd expect to see two separate features:
1) M:N callback mechanism
2) delayed on-thread execution of a function

Delayed execution on the current thread is no different than on any other
thread.

The cross-thread signal-slot delivery can be implemented by combining both.
Something like:

  connect(sender, signalId, [=] { executor->queue([=] { action(); }); });

That is to say, I expect the standard way to be far more verbose and explicit
than the Qt way. That has always been the case and continues to give me
something to add to the library (q.v. QRandomGenerator).

Whether the first feature is valuable by itself without the second, I can't
really say. I expect so, especially if it has the same value as Qt signals in
that you can add to a class without causing it to grow in size.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering