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
