Godot-proposals: Always display exported float variables with one decimal, even when whole numbers

[Arnklit]

Describe the project you are working on:
A fur plugin for Godot

Describe the problem or limitation you are having in your project:
I'm having issues with not being able to show exported int variables as sliders. See https://github.com/godotengine/godot/issues/42809.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Part of the reason for not displaying sliders on ints, according to the bug mentioned above, is to easily distinguish them from floats. So it would seem a good improvement to make it easier to distinguish floats by always having them display a decimal.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

If this enhancement will not be used often, can it be worked around with a few lines of script?:
This enhancement would be used often.

Is there a reason why this should be core and not an add-on in the asset library?:
This would have to be changed in core as far as I understand.

[aterlamia]

I was already doing some research for the linked issue and also asked on irc and got this as answer

"aaronfranke[m]
Always showing a decimal for floats is a neat idea but it needs to be discussed and applied consistently around the engine. Currently floats that are whole numbers don't show .0"

If it needs to be implemented everywhere it is displayes it might be as easy as removing the "//destroy trailing zeroes" part from

String String::num(double p_num, int p_decimals) in ustring.cpp. If the functionality is still needed for other places or this change will only need to be for the sliders a new function or a toggle (something like String String::num(double p_num, int p_decimals, bool p_keep_trailing_zero)) needs to be added.

And then the code

String EditorSpinSlider::get_text_value() const {
    return String::num(get_value(), Math::range_step_decimals(get_step()));
}

in editor_spin_slider.cpp should be changes to use that new function.toggle

(sorry readded this commit as i added it from a wrong account)

[Bhuvan-Vemula]

Hello,
So any core members are interested In this feature. Personally, I like the idea.

[Calinou]

@Bhuvan-Vemula Sure, feel free to open a pull request for this :slightly_smiling_face:

[Calinou]

@Bhuvan-Vemula Any progress on this? If you don't plan on implementing this feature, please comment so that someone else can do the work.

[akien-mga]

For the reference, I'm in favor of this change, and other core devs mentioned support too in an informal discussion today (@vnen, @groud, @Calinou). It should be done both for the editor (Inspector, Debugger) and for printing/serialization.
I.e. any situation where a float is whole, it should be represented with .0 suffix to be properly distinguished from its integer counterpart.

Over the years this has been a constant source of confusion for new users who do not fully understand what data types they are using behind the scenes with e.g. var a = 5, var b : int = 5 or var c : float = 5. Or worse, with vector types like Vector3(1, 2, 3), which users often wrongly expect to be storing integers (which is now possible in Godot 4.0 using Vector3i).

On the other hand code like var c : float = 5 should still be valid as is, even if print(c) should display 5.0. Only the representation should be changed, not the language itself.

The change should be done for the master branch in priority, and can break compatibility.

We can eventually consider if a backward-compatible change could be added to 3.2 (but then maybe only for the editor display, not for serialization, as this would be a compat breaking change).

[akien-mga]

@Bhuvan-Vemula Any progress on this? If you don't plan on implementing this feature, please comment so that someone else can do the work.

I don't think their comment implied interest in doing the implementation work, only checking if there is support from the developers. So this task can be taken by anyone interested.

[1shevelov]

I want to support @akien-mga's arguments with an one more example which I stumbled upon recently:

var arr: Array = []
for i in 3:
    arr.append(float(i))
print(arr)
print(arr.find(1))

And the output is:

[0, 1, 2]
-1

And this could be very confusing for newbie programmer since the output doesn't give a hint on what the problem is (why find(1) returns "not found" while print() shows that there is a "1" in the array).
Another good comment on the topic here.