Fully implement C-style the printf format strings including %g

[goatchurchprime]

I was having some difficulty for a non-zero value that was zero when I printed it out, like so:

var x = 1.0e-14
print("x is %f but comparison to zero is %s" % [x, (x == 0.0)])

x is 0.000000 but comparison to zero is False

(These sorts of problems come about because we use Radians instead of Degrees in all rotational calculations, and therefore cannot accurately define right angle rotations without introducing these not-quite-zero values in the vector components. But that's a different rant.)

Normally I can make it easier by using a "%e" or "%g" in the format string so that non-zero values become visible, but I can't do this in GDScript because it's missing these particular placeholder types as stated in the documentation. Meanwhile, the C++ documentation calls them format specifiers.

Instead, GDScript gives the error "unsupported format character in operator '%'." when I try and use a "%g".

This error string appears sourced from the function GDScriptFunction::call():

err_text += " in operator '" + Variant::get_operator_name(op) + "'.";

combined with the default case of the switch statement in String::sprintf():

return "unsupported format character";

A new non-standard format character of "%v" was just added to the core library two months ago, so isn't available in my Godot3.5.

The question for discussion is why have an implementation of this format string system in core code all, instead of using stdlib::sprintf() directly or a third-party implementation as we do with the RegExp at a fundamental level?

This would have the advantage of being more standardized with less maintained code in the core system for a rather finickety function that is hard to get right in many bug-producing edge cases.

There is one work-around for me, which is to use var2str() when printing out my values, because this calls String::num_scientific() in which sprintf("%g") is used.

But if the "%g" format specifier is essential for use down there, why shouldn't it be available to normal GDScript users who may be exporting runtime debug/log files of geometric positions for accurate off-line analysis?

[Calinou]

Feel free to open a pull request for this 🙂

The question for discussion is why have an implementation of this format string system in core code all, instead of using stdlib::sprintf() directly or a third-party implementation as we do with the RegExp at a fundamental level?

See Guideline 8 in Best practices for engine contributors.

There are many single-header string formatting libraries out there, but replacing existing core functionality with one of them entails a lot of development work that could be otherwise avoided. I'm not sure if the tradeoff is worth it, even in the long run (in case the library in question ends up unmaintained).