Convenience function to cast / convert to other types

[NigelBreslaw]

I still find code like this unnecessarily complex width: self.source.width / root.frames-wide * 1px;.

Even though it's technically the same thing, would it be possible to have px(width: self.source.width / root.frames-wide) and postfix (width: self.source.width / root.frames-wide).px(). Or toInt() or whatever the best name is. It would make the language look more friendly to new starters (especially design folk), you don't have to understand math order of operations, etc.

[ogoffart]

We could add that, although i'm not sure .px() is friendlier than *1px or /1px.
Especially since the error message already hint for it.

What we could improve is make it a structured suggestion so that the LSP could fix it automatically.

[NigelBreslaw]

If KDAB or our other partners do any Slint training can we keep an eye out for this? My hunch is that it's not just about clear errors. They are clear already. It increases the barrier to entry for Slint. You hit these issues immediately and it just feels like it will trigger math shame in some potential users. You can easily follow the advice of the error but not grok the concept of coercing the value to another type. Being able to wrap stuff and just say be an angle or be pixels i.e px(what ever complex expression you have) could be simpler for a fair chunk of people.

Convenience functions might not be the way to go. Could more places auto do the right thing? As in if you know the type the property expects, auto convert it to the correct type. But we should keep an eye on this. If it's rare anyone is tripped up by this, then no worries. Be surprised though.

[tronical]

What we could improve is make it a structured suggestion so that the LSP could fix it automatically.

That's a great idea in any case.

Another syntax we could consider is ... as px.

[NigelBreslaw]

Another syntax we could consider is ... as px.

Even though I think this might be a trap for me 😂 that looks much nicer

[szecket]

I'd read
width: px(self.this + root.that);
or
width: self.this + px(root.that);
better than including the width: in the paren...

but we'd need to namespace them as you're going to get
.s, .ms, .px, .mm, etc.
we could Convert.ms(blah) like Math.sin...?

[ogoffart]

Another syntax we could consider is ... as px.

The problem with that is that this could be quite ambiguous grammar unless we make as a keyword and then we need to forbid the use of as as property or id.
(Although I think it might actually not be ambiguous. But the @linear-gradient syntax already allow space between two consecutive expression, but not 3 afaik)

better than including the width: in the paren

I understood it was just a typo and width: shouldn't be in the paren

we could Convert.ms(blah) like Math.sin...?

We can already do

global Convert {
   function px(x: float) -> length { x*1px } 
   function ms(x: float) -> duration { x*1ms } 
   // ...
}

:-)

It increases the barrier to entry for Slint. You hit these issues immediately and it just feels like it will trigger math shame in some potential users.

I see. I didn't get this feedback before. Worth keeping an eye on it.

As in if you know the type the property expects, auto convert it to the correct type.

The whole point of a type safe language is that it doesn't, because you don't want to mix a size and some value.
But we can provide an auto-fix in the LSP that adds the *1px

[ogoffart]

Regarding the suggestion that adds the *1px: #108