[Development] Redesigning QML value types

Ulf Hermann ulf.hermann at qt.io
Wed Sep 21 14:59:08 CEST 2022


Thanks for the feedback! I've thought about it some more and done some 
experiments and I think we can solve this in a way that makes everyone 
happy:


If a function has type annotations, we pass its arguments and return 
value by value (if they are value types). Otherwise we pass by 
reference. Inside a function, everything is a reference.


This makes some intuitive sense: The type annotations are QML types, not 
JavaScript types. You might expect QML _value_ types to be passed by 
value. As long as the arguments and return values (or indeed the locals 
on the stack) are untyped, we're firmly in JavaScript land.

You also get to keep the convenience of "o.a = 10" and similar 
constructions this way, and we can seemlessly extend that to more deeply 
or differently nested structures.

Remember that qmlsc and qmlcachegen only compile typed functions to C++ 
and the generated code will also only call typed functions. This means, 
with the above proposal, our AOT-compiled functions don't have to pass 
value type references as arguments or return types. Therefore, we can 
leave the compilers as they are. Otherwise, if we had to pass value type 
references instead of actual value types between our AOT-compiled 
functions, their signatures would have to change. That would have 
user-visible effects on the metaobjects. Plus, if we were to return 
value type references from functions, we'd have to allocate at least 
some of those value types on the heap, and garbage collect them at some 
point. I feel we really shouldn't go there.

The downside is that we have to swallow a behavior change in interpreted 
code: So far the QML engine passes everything by reference and now it 
will have to detach the arguments and return values when calling or 
returning from a typed function. However, since the primary reason to 
annotate your functions is to get them compiled to C++, and since qmlsc 
and qmlcachegen already generate code that behaves the new way, this may 
not be all that hard.

best regards,
Ulf


More information about the Development mailing list