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
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
