Add support for local variables

[tronical]

We should support local variable to be able to cache intermediate computation result in a binding.

So we could do things like

function foobar() -> int {
    let value = compute-value();
    return value != 0 : root.property / value ? root.some-other-value;       
}

In other word, add support for

let something = <expression>;

in the Slint language.

Discussed in #2751

^{Originally posted by loloof64 May 18, 2023}
Hi, is it possible to define local variables in ui scripts components/functions ?

I mean something like this for example

export component MySquare inherits Rectangle {
    width: 100px;
    height: 100px;
    background: red;
    in property<string> items: "abcd/efgh/ijkl/mnop";

    public function get_items_arr() -> [string] {
        let arr = [];
        for elt in items {
            if (elt != "/") arr.push(elt);
        }
        arr
    }
}
```</div>

[ogoffart]

Local variables might make some sense. But i would be hesitant to implement for loop.
Our strategy had been to keep the language intentionally simple because the actual logic should be written in native code.

[ogoffart]

We would need to decide a syntax for it.

I'd go with let as this is the same syntax as rust and typescript.

let foo : string = "123";

(type annotation optional)

[Tmpod]

I agree with this. Having variables is useful sometimes, but Slint shouldn't really go deeper than that, and let the backend language handle that.

[hunger]

Maybe variable <string> foo: "bar"; ? That would align with the property syntax a bit more closely.

Or var <string> foo: "bar"; ?

[FloVanGH]

The code for the timer picker #5087 would also profit from local variables.

[tsaxking]

We would need to decide a syntax for it.

I'd go with let as this is the same syntax as rust and typescript.

let foo : string = "123";

(type annotation optional)

Has there been any update on this feature? I would love this!

[Gibbz]

I was struggling with this today too! As a new user I couldn't figure this out, and didn't realise it was not implemented.

I'm trying to create a new point, and assign it to an array. I guess this needs to be done in rust instead of slint, then passed back to slint. Which is fine, I just didn't know 👍

[ogoffart]

Complex logic with for loop should be implemented in callback in native code.

Local variables would be sometimes quite useful to store intermediate result.

A workaround (which is not a replacement for it but can be useful sometimes) is to use an intermediate function:

function foobar() -> int {
    return foobar-impl(compute-value());
}
function foobar-impl(value: int) -> {
    return use(value, value*2);
}

// Instead of 
// let value = compute-value();
// use(value, value*2)

[ogoffart]

I'll tag this as good-first-issue to mean that if someone really wants this, they can give it a shot at implementing. It is not trivial, but being localized in the compiler frontend it should be doable by anyone who can write rust code.

Here are how to do it:

1. Actually parse the let identifier = statement in

   slint/internal/compiler/parser/statements.rs

   Line 18 in edbcab7

   pub fn parse_statement(p: &mut impl Parser) -> bool {

2. This should produce a new node kind in the CodeBlock defined around

   slint/internal/compiler/parser.rs

   Line 370 in edbcab7

   CodeBlock-> [ *Expression, *ReturnStatement ],

3. In the resolving pass, that new node should produce an Expression::StoreLocalVariable. probably around there

   slint/internal/compiler/passes/resolving.rs

   Line 188 in edbcab7

   fn from_codeblock_node(node: syntax_nodes::CodeBlock, ctx: &mut LookupCtx) -> Expression {

   
   and store the type of that expression in the LookupCtx for further access.
4. In lookup.rs, add the code to find that local variable later.

   slint/internal/compiler/lookup.rs

   Line 879 in edbcab7

   pub fn global_lookup() -> impl LookupObject {

   
   Should be similar to the existing ArgumentsLookup, but generate a Expression::ReadLocalVariable
5. Add tests in tests/cases/expr or tests/cases/lookup or somewhere where it fits. (this step could also be done first, for TDD. What I'd do is just to use it in a small .slint file, and try to run the viewer over it until it works)
6. Don't forget documentation

That should be it.