This becomes more and more non-intuitive. let a: font = f // copy f because a is value-typed? let b = a // copy because a is typed, and b's type is inferred from a? let c = f // ref because f is JS-ish type function foo(arg) { return arg } let d = foo(b) // ref because f is JS-ish type ? or copy because a is typed, and b's type is inferred from a? let b = d // ref?
Regards, Konstantin ср, 21 сент. 2022 г. в 19:45, Ulf Hermann <ulf.herm...@qt.io>: > > Generally I feel that all the gritty details in what to do and what > > not do in qml to have efficient, compiled code, are more and more > > confusing. There is so much to consider and basically all the > > documentation about this is hidden in Qt blog posts. > > Well, yes. All of this is 10 years late and we have to shoehorn it into > an existing language with compatibility promises. So, some inconsistency > cannot be avoided. I'm doing what I can to avoid confusion, though. The > blog posts are in fact being transformed into regular documentation. It > takes some time, though. > > > Anyway I'd just like to note that, as far as I can remember, type > > annotation are currently not supported in lambdas (=> syntax). > > Indeed not. Type annotations are mostly meant for methods of QML types, > which cannot be phrased as arrow functions. The only other place where > they might be beneficial is in inner functions inside bindings or > methods. The compilers cannot generate efficient code to call those, > yet. Therefore it doesn't make much sense to annotate them, yet. We'll > get back to that when we get there. Help is always welcome, by the way. > > regards, > Ulf > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development