Default values for struct fields

[ogoffart]

It is often requested to have default values for struct fields

It could look like this:

struct Player {
     score: int = -1,
     name: string = "John Smith",
}

Then, when initialized, or converted from a struct with less fields, the other fields are initialized with thei default value:

component X {
   // initialized to default values
   property <Player> player1;
   // score will be -1
   property <Player> player2: { name: "Alex" };
}

The Default implementation of the rust structure or C++ default constructor must initialize the fields accordingly.

[tronical]

Straightforward syntax, and very sensible. I'm much in favor.

[hunger]

I see myself mixing up : and = as we use : for assignments pretty much everywhere else.

Could we maybe do something like

struct Player {
     <int> score: -1,
     <string> name: "John Smith",
}

That is of course breaking the existing struct definition syntax... which I can remember well as "assigning a type to the field name":-)

[Tmpod]

Yeah, there's a bit of a syntax conflict here. Using = in this case seems a bit out of place, but : clashes with the type specifier.
I wouldn't be against changing the struct field declaration to be more akin to property declaration, like @hunger suggested. It would make Slint's syntax more consistent overall, lowering the learning curve a bit.

[Enyium]

I'm not sure there's a syntax conflict here. Slint uses : for property bindings, similar as in CSS, and = for assignments in code that's executed line by line. The syntax currently used in structs name: type is also used for parameters of functions, which are associated with line-by-line execution. If Slint would allow default values for function parameters, name: type = default would also be a natural syntax. If you'd want to argue in favor of another syntax, you'd need to bring property-binding-associated uses of structs into the field.

[ogoffart]

Since slint is structurally typed, this turns out to be quite difficult

Consider:

struct MenuItem {
   title: string,
   enabled: bool = true,
}

component Bar {
   property <MenuItem> hello: some_condition ? 
          { title: "Hello" } : { title: "Hello", enabled: false };`
   property <[MenuItem]> list: [ { title: "Hello" }, {title: "World", enabled: false} ];
}

For hello, when resolving the binding, we first resolve the sub expression of type (pseudo-code)
<bool> ? <{title: string}> : <{title: string, enabled: false}>
The type of this sub-expression is {title: string, enabled: false}
Since there is no reference to the MenuItem and its default values, it will just not work (at this stage, the left hand side of the : will be converted with enabled being false as this is the default value for bool and not the setter from MenuItem.
Same problem for the list property.

In order to be able to make this work, we'd need to resolve things up side down and know the final type of what we are converting.

Same explanation for this:

   function foobar(item: MenuItem) { debug(item) }
   init => {
      foobar(condition ? { title: "Hello" } : { title: "Hello", enabled: false });
   }

So in other word, this would depends on something similar to #897 where we need to propagate the expected type of a sub-expression in order to resolve that sub-expression