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

Reply via email to