Qt 5.0 released

You need those for the traditional variant of connect.

Are you saying that the two markup alternatives you mentioned can provide the necessary introspection data for runtime checked connect on base class pointers?

Otherwise I am a bit puzzled considering the compile time checked variants of connect seemed what you would be going for.

> just that it does effectively make Qt-using sources a non-standard C++ dialect as a result.

Hmm, I am afraid I can't follow you here either.
Given that the content is perfectly consumed by a wide range of C++ compilers, wouldn't that indicate that it is using standard C++ dialect?

Or are you saying any form of preprocessor substitution makes something non-standard C++? How does on solve includes and include guard using standard C++?

> Sure, I understand the historical reasons, and they make perfect sense in this context.

You must have put this sentence into a wrong line by accident, since it does make not sense in the context of the quoted line.

Not relying on a custom compiler for every platform does still make perfect sense in present context.

That's why Qt code has not, does not and almost certainly will not require a custom C++ compiler but will continue to work with the compilers that compiler or platform vendors release.

> But all the other signal/slot mechanisms such as sigc++ and
> boost::signals require nothing except compiler template support,
> which all compilers have supported for well over a decade now.

I wasn't aware that those libraries provide runtime connect based on introspection of base class pointers.
Maybe this could be added as a third option to Qt, leaving the traditional connect for compatibility (which is needed anyway), having one of those mechanisms you describe here taking the role of the runtime use case and the member/functor connect for the compile time use case.