This is just a minor QoL improvement - it'd be nice to have an export hint for int and float types that allows you to specify whether you'll only allow positive/negative values (including 0). I know the feature can be emulated with export(int, 0, [large number]), but then you're made to decide what constitutes an appropriately large upper bound or lower bound.
I'd like to propose a simple 'shortcut' in the following form:
export([int/float], POS) is effectively an alias for export([int/float], 0, [int_max/float_max])
Similarly, export([int/float], NEG) is effectively an alias for export([int/float], [int_min/float_min], 0)
This isn't a majorly important suggestion nor do I have any idea how easy or hard it would be to implement, but considering the amount of times I've wished I could say "I want this export field to be valid for any positive number" (namely with things like speed, size, et cetera) I figured I would make the suggestion.
A more flexible variant of this could be to allow emitting either the min or max limit. So for example, export(int, 0) to allow only positive values, or export(int, ,-1) for -1 and smaller.
EDIT: Or maybe not, since that would break the current functionality where using just a single argument uses that as upper bound and 0 as minimum.
I'm thinking of picking this one up. I am wondering though about adding a new keywords for POS and NEG. The only other option I can think off the top of my head would be to re-purpose INF and -INF. Anyone have any opinions?
@kitsune Reusing INF/-INF and flipping the range when only one negative number is given (so, export(int, -10) becomes export(int, -10, 0)) sounds like a legit way to do this. 馃槂
Inf and -inf are float types, you really shouldn't (and probably can't) use them in an integer context.
You also can't compare them, and theoretically there are platforms where you can't have a static infinity value at all.
So one would use export(int, INF) and internally you would have export(int, 0, INT_MAX) or one might use export(float, -INF) and internally you would have export(int, FLOAT_MIN, 0).
@hpvb, GDscript doesn't currently have INF and -INF defined in the context of the export function. Although you are right to question overloading it in such a fashion. I was merely offering an alternative to creating two new reserved keywords in the language POS and NEG.
While it doesn't completely solve this issue a third option is simply to add INT_MAX INT_MIN FLOAT_MAX FLOAT_MIN as constants. While this would add 4 keywords it would solve the problem of using an arbitrarily large or small number and the constants might be useful in other places. Doesn't really have the same QoL as the original proposal though, but may be more acceptable.
@kitsune I personally agree with @hpvb here; considering the general expectation that INF/-INF in programming is reserved for the results of certain float operations, I feel like it'd be bad form to use them in this context.
I'm a bit surprised that Godot doesn't already have INT_MAX, etc, but I haven't delved too far into looking for it. If they don't exist, though, I see no reason they shouldn't, although I'm not sure that exactly falls under the category this issue is describing. (That said, I wouldn't be opposed to using the min/max values as a solution instead if the pos/neg thing becomes a hassle).
When I proposed the original suggestion I had the idea to create the POS/NEG keywords because we already have several similar export hints; they can be found here under the PROPERTY_HINT_* values - things like FILE, DIR, MULTILINE for text, or EXP for a float. I can't say I fully understand Godot's inner workings well enough to say for sure, but it seems to me, at least, that creating POS and NEG in similar fashion to those examples would have marginal downsides if any at all.
I don't know why i didn't think of doing something like that. PR incoming,
Removing the "junior job" label, this requires some refactoring of the hint system to implement this correctly.
Note that with the new or_lesser and or_greater hints in dfd13316, it should be possible to implement this with a PROPERTY_HINT_RANGE and a hint like "0,1000,0.01,or_greater" (slider from 0 to 1000 with step 0.01 in the inspector, but you can input values above 1000 if needed) or "-2048,-0.01,0.01,or_lesser" (slider from -2048 to -0.01 with step 0.01, with option to input values below -2048).
What prevents you from using export(float, 0, INF) or export(float, -INF, 0)? I know that this can't be done with integers, but why isn't this already good enough for floats?
Most helpful comment
While it doesn't completely solve this issue a third option is simply to add
INT_MAX INT_MIN FLOAT_MAX FLOAT_MINas constants. While this would add 4 keywords it would solve the problem of using an arbitrarily large or small number and the constants might be useful in other places. Doesn't really have the same QoL as the original proposal though, but may be more acceptable.