[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