WIP: normalize macro

[WilstonOreo]

syntax tests fail for some reason

[hunger]

So I assume its normalize(value, minimum, maximum)? IMHO that could be a bit clearer in the description.

IIRC we can not extract the argument names that go with those Ts in the list of arguments :-(

[ogoffart]

Thanks for the PR, and nice that you could get it working.
However, I'm torn whether it is useful to add this builtin.
I don't think this is something one need to use that often, and it is really easy to do it without it with just a few operations.
So i'm thinking we shouldn't continue on this.

The other thing you mention to have foo.clamp(0, 1) or foo.min(bar) might be interresting to fix however (i filled #5328 about it if you want to have a look)

[tronical]

Same here: I don't feel too strongly about this, but I'm unsure if this is a frequently used function that should be in the standard library - especially as global function.

[WilstonOreo]

The initial use case I thought was to determine the relative position in a slider or progress bar.
And in std-widgets style, there are a few cases indeed, but it would save only about 1 line of code for each use :)
Moreover, after reading the source code of the styles, I noticed there are quite a lot of redundancies and I think it would be much better to have templates with a defined interface for each stylable widget instead, e.g.:

export component SliderTemplate {
in property <float> value: 0.0;
in property <float> minimum: 0.0;
in property <float> maximum: 0.0;
out property <float> level: (value - minimum) / (maximum - minimum); // Our normalize function
};

If you want, I can open another issue to track this.

[ogoffart]

Regarding the code duplication in style, yes, we thought about that.
We are considering interfaces (tracking issue 1870) as well as common base that could even be public. (eg, SliderBase although in that case it's not a base component)