Export range doesn't work with step size

[gamma-delta]

#[derive(GodotClass)]
#[class(base = Node)]
#[allow(dead_code)]
struct MyStruct {
  #[export(range = (0.05, 1.0, 0.05))]
  foo: f32,
}

This fails with error: expected identifier on the 3rd number.

The gdext docs don't say how to use step size in range at all, but I would awfully like if I was able to do this.

If it is possible, it would be nice if this was documented.

If it's not possible, it would be nice if it was implemented.

[gamma-delta]

https://github.com/godot-rust/gdext/blob/master/godot-macros/src/class/data_models/field_export.rs#L31

Looks like it's not implemented at all...

[lilizoey]

ah yeah i made a mistake there, as a workaround you can use #[var] with a custom property hint, hint_string, and usage flags.

[Bromeon]

Looks like a small oversight.

@gamma-delta Would you be willing to add support for step in a pull request? 🙂

[gamma-delta]

I can try!

It looks like it's going to be a little complicated because it specifically expects that there are exactly 2 numbers, then possible strings. I'm not sure how to handle this because it lets you put whatever expr you want in anything else, so do I check if it's a number at macro-time? or afterwards somehow?

[gamma-delta]

for now i'm just going to divide everything by 1000 in rust 😓

[StatisMike]

Should we require the step, or make it optional?

[Bromeon]

If we keep following the current API design, we should probably allow different syntaxes like Godot, meaning the tuple can have different lengths (with appropriate defaults).

Some key-value syntax might be an option, but it's quite verbose, and not sure if worth it.

[StatisMike]

EDIT: Nevermind below musings - ListParser refactor wasn't that great, and optional step was very possible. It's maybe not the most elegant solution, but I know next to nothing about macros.

Didn't feel competent enough to tackle integer, though. Float seem serviceable.

@Bromeon It seems there is more functionality missing from the @export_range() gdext implementation:

https://github.com/godot-rust/gdext/blob/master/itest/rust/build.rs#L427-L430

It seems to me like it would warrant a little refactor of the ListParser to allow such changes, and probably should be tackled simultaneously: both adding support for step and integer support.

[lilizoey]

Didn't feel competent enough to tackle integer, though. Float seem serviceable.

my idea for integers would be to make the export_range function generic over some new internal trait, and implement that for whatever types make sense (i think just floats and integers?).