[jcelerier]

> This misses my point. If I create a language and assign different semantics to the Python AST,

but which semantic differences are you talking about ? It is plain C++. Function calls are function calls, the only difference being that some are auto-generated and some are your own code.

[weberc2]

C++ has no notion of signals and slots or other metaobject utilities. Your editor cannot autocomplete those signals/slots like Qt Creator. Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.

[jcelerier]

> Your editor cannot autocomplete those signals/slots like Qt Creator.

what do you mean ? signals and slots are just plain functions, there is no magic to understand ; the only thing that QtCreator does is to display a different icon in the autocompletion toolbox.

Do you have an example of an IDE that is not able to autocomplete a signal ? VS is able to, vscode is able to, Xcode is able to, code::blocks is able to, hell even notepad++ in all its "non-intelligence" manages to.

> Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.

I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.

[weberc2]

Signals and slots compile into plain C++ functions. The input language (the unnamed Qt superset of C++) has a notion of signals and slots, the output language (C++) does not have any such notion.

> I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.

My point does make sense, you're just missing it.

First of all, my point is that Qt is a poor developer experience--that its interface is bastardized is merely evidence. Further, even if it were not bastardized, it would still be awful because it's C++ (insane build tooling, no package management, poor error messaging, no memory safety, enormous feature matrix, etc etc etc; all of this has been covered elsewhere ad nauseum, no need to repeat those arguments here). There's a long tail of additional issues with Qt that contribute to its unpleasantness, but there's no point in diving into them here.

Secondly, your stateful library functions example doesn't fit my criticism because stateful functions are part of the C++ language spec while signals and slots are not.

[jcelerier]

> Signals and slots compile into plain C++ functions. The input language (the unnamed Qt superset of C++) has a notion of signals and slots, the output language (C++) does not have any such notion.

If that was the case, gcc and clang would not be able to build Qt files. Yet the following compiles without issues :

    echo "#include <QObject>\nstruct foo : QObject { signals: void bar(); public slots: void blah() { } };" | g++ -std=c++11 -fPIC -I /usr/include/qt/QtCore -c -x c++ -

which is all that is needed to ensure that some code is indeed 100% valid C++ code - that it is idiomatic is a wholly different question.

hell, you can even generate the signals code without moc if you are ok with more macros (https://github.com/woboq/verdigris)

[weberc2]

No, it just means that Qt is valid C++, not that the two have equivalent semantics (which is necessary for Qt to be exactly C++ and not a bastardized version thereof, which is what we are debating). If I we’re wrong and you were right, the moc would be purely optional; it would serve no purpose, and Qt programs compiled with moc would behave exactly as those compiled without.