Floating point format options

Question

I've just dipped my toe into Zig, but it seems to be lacking the floating point format options which are common in C and C++, namely the "f" and "g" options, so that, for example, (7.0 / 3.0) will display as 2.33333 by default, instead of 2.3333333333333335e+00. Is that on purpose and if so, what is the rationale, or simply an oversight?

Answer 1

Format string parameters are described here.

You can provide width and precision, among other options. To print a decimal number, use d (this is not just for integers), and to print a floating point number in scientific notation use e. For example:

const print = @import("std").debug.print;

pub fn main() void {
    const x = 2.0 / 3.0;
    print("x = {d:6.5}\n", .{ x });
    print("x = {e:6.5}\n", .{ x });
}

Program output:

x = 0.66667
x = 6.66667e-01

Regarding "...the floating point format options which are common in C and C++, namely the f and g options....": the f and g conversion specifiers aren't just common, the C Standard mandates them in the specification of the Standard Library. Many languages have adopted C style conversion specifiers to greater or lesser degree, but this isn't universal.

Zig does provide for formatting floating point values in decimal notation or scientific notation using d or e, respectively. These roughly correspond with C's f and e conversion specifiers. There is no option in Zig corresponding with C's g conversion specifier, which determines decimal vs scientific notation based on the specified precision and the size of the exponent if the value were formatted in scientific notation.

Why doesn't Zig have an analogue to g? Only the core developers could answer that question. Note that Zig is still early in its development (v0.11.0 is just around the corner at the time of this writing), and the Zig Standard Library in particular is considered tentative. It is possible, even likely, that the formatting facilities will be augmented and improved in the future. Note that there are many other formatting facilities described in the C Standard specification of format string semantics that are not currently supported by Zig; to single out g seems arbitrary.

It is even possible that the core developers feel like the semantics of g conflicts with core Zig principles, i.e., the rules for choosing decimal vs. scientific notation for g are not particularly arcane, but most C programmers probably couldn't tell you exactly what they are off the tops of their heads. Zig values clarity and explicitness, and you could make a case that g conflicts with this value.

I don't know if Zig developers hold this last view. I wouldn't mind at all if some g-like functionality were added to the Zig formatting string mechanisms. Zig's format string capabilities still feel incomplete to me at this point, so maybe this particular feature will be added with other improvements in the future.