[Development] Redesigning QML value types
Ulf Hermann
ulf.hermann at qt.io
Wed Sep 21 20:17:04 CEST 2022
> This becomes more and more non-intuitive.
>
> let a: font = f // copy f because a is value-typed?
That syntax doesn't exist in QML. You can only type-annotate function
arguments and return types, but not locals.
> let b = a // copy because a is typed, and b's type is inferred
> from a?
That statement by itself is a no-op in JS. It just adds another name to
the value referred to by a. Here you have one of the reasons why I'm
hesitant to add further syntax like you propose above. I would also have
to add extra byte code instructions, invent semantics for them, and
figure out how that would interact with the ECMAScript standard.
> let c = f // ref because f is JS-ish type
Here we just load f into a local and form a value type reference. That's
the only thing you can do when loading a value type from a property.
> 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?
Here we're indeed not in Kansas anymore.
> let b = d // ref?
Well, it's wicked. Let's never allow typed locals!
More information about the Development
mailing list