Consider the following scenarios:
- header file path with all generated functions (their declarations)
- installs every binding
- evaluates them once
- sees whether bindings could be removed
qmlsc, on the other hand, should be able to see this ahead-of-time and basically generate constant expressions. If this is the case, qmltc might benefit from exposing such directly and it needs:
- the expression (with a guarantee that it evaluates to the type convertible to the corresponding property type)
As in the case of the general pattern, no assumptions on whether everything has to be compiled to C++ are made. Exposing expressions (essentially generated function definitions) allows to convert a binding setup into a property assignment, which is usually a much simpler construct.
If a user can guarantee that myText.text is unmodified within the whole QML application, myText.text and myText.text.length essentially become constant values that we can propagate around the document. This means that Rectangle's width also becomes constant and so on. The problem in general is that the user could modify myText.text from C++ and our tooling would definitely miss that. One solution is to introduce an expression annotation (e.g. "immutable"/"constexpr"/"consteval") to mark every non-modifiable expression as constant, thus allowing qmlsc to understand what it could optimize and fail at run time if properties ( ? ) with constant expressions get modified.
This, however, truly requires QTBUG-96548.