Upcoming Changes to the Slint Language

[ogoffart]

This is the discussion for the blog post "Upcoming Changes to the Slint Language"
-PART 1
-PART 2

We are welcoming your feedback. See also the meta-issue #1750

[jrmoulton]

I feel like the old syntax for inheriting from another component could be more consistent and clear. And while I feel like explicitly writing "inherits" makes the intent more clear I definitely don't like it.

Maybe using the same syntax as what rust does for declaring required traits would work.

component AnotherComponent: MyComponent { /*...*/ }

What is the reasoning for switching to explicitly writing "inherits"?

[jrmoulton]

Also as a side note a syntax overhaul would be a good thing because it would give me an excuse to rewrite the treesitter parser

[ogoffart]

One thing is that we want to discourage inheritance. (Composition over inheritance)
Inheritance makes the property of the base part of the interface. So if you inherit rectangle, you get a background and border properties you might not want. For example we noticed people where using these properties on the widget on the style, and then they would have build error when changing style.

[jrmoulton]

One thing is that we want to discourage inheritance. (Composition over inheritance)

Inheritance makes the property of the base part of the interface. So if you inherit rectangle, you get a background and border properties you might not want. For example we noticed people where using these properties on the widget on the style, and then they would have build error when changing style.

Ahh that makes sense. Ok the proposed change would make sense then

[jrmoulton]

Haha well I actually did end up going back and rewriting the tree-sitter grammar. Good fun.

It had been a while since I had used slint so it was a good reminder of the things in the language that I find funny. The biggest issue I have is with the for loop syntax. It still feels unintuitive to me. It would add a little more noise but I think it would be more consistent with how for loops worked if the for loop just opened a body and then inside of that body the component was created.
Eg

    for tile[i] in memory-tiles {
        MemoryTile {
            x: tile-spacing + mod(i, column-count) * (tile-size + tile-spacing);
        }
    }

To me this makes a lot more sense and is a lot closer to regular for loops. And I'm my mind this would allow for instantiating other components inside of that for loop as well. Makes sense to me.

My other biggest challenge with the language (and this becomes very apparent when writing the grammar) are the inconsistencies with expressions. I'm sure there is probably a good reason but I don't know why some expressions are only valid in some contexts, such as if expressions inside of callbacks handlers. Functionally I don't think this actually ends up making UI's too much more complicated but it does just feel off and inconstant in a way that is distracting.

[tronical]

I love the feedback about the for loop syntax :)

[ogoffart]

Filled #1873 for loop syntax.

Note that syntax-wise that might be easy to change. But internally, the compiler and runtime currently assume that the dynamic tree can only generate a single (runtime) Component (item-tree). So that would be a deep change in the compiler and runtime to support that.

inconsistencies with expressions. [...] I don't know why some expressions are only valid in some contexts, such as if expressions inside of callbacks handlers.

Could you elaborate?
Are you talking about the the difference between code blocks and binding expression.
Like

// no "if" allowed in there
foo: cond ? true : false;

// code blocks: allow "if"
foo: {
   if (cond) { return true; } else { return false; }
}

// But you can't have (this is not allowed by the parser)
foo:  if (cond) { return true; } else { return false; };

// "if" is NOT an expression, so you also can't have
foo: {
   if (if (cond) { true } else {false}) { return if(someting) { bar } else { baz }; } else { return false; }
}

Which is the duality between statements and expression.

Maybe we should change the syntax to be an expression base syntax like rust is?

[ogoffart]

Update: Part 2 published: https://slint-ui.com/blog/changes-to-the-slint-language-part-2.html