After searching the forum about that topic and understanding pretty little of what I found (but most of it seems collateral to my main question), I keep needing them.
Sure,
including in the code base only the formatting code actually needed is nice (even if code size in most cases is not the most pressing concern),
having the correspondence between format codes and parameter types checked while compiling is even nicer, but
not being able to do any formatting with format string known only at runtime is bad.
For instance, I have ready a small collection of Zig packages implementing a) locale detection, b) locale-driven GNU-gettext-like multi-language outputting with 26 pluraliser functions covering the needs of 220+ languages and c) PO/POT extraction from Zig sources, but I am stuck as it can be used only with fixed, non-formatting strings, making useless all the plural management and then partly useless the whole thing (I kind of knew this from the beginning, but I tried anyway, also as a way to familiarise myself with the language).
Am I missing something? Are there alternatives I am not aware of? Any hope the language will ‘soon’ support at least some form of runtime-known format strings or shall I ‘simply’ implement the missing parts myself within my packages? (Actually, I could do with just supporting “{d}” and “{d}”). Or shall I just rely on ‘C’ compatibility and resort to GNU-gettext itself?
I believe the mechanisms to store anytype of arguments and any number of formatting ‘positions’ i.e all the ‘{d}’ requires some allocation/type erasure we don’t find anywhere else. Since your use case seems to be about localization, I guess you only need to store strings as argument, which could make your problem both easier to solve and less interesting to have in a standard library.
Security. Comptime-known format strings eliminate an entire, very tasty class of stack-smashing exploits.
This sounds pretty cool!
You would not find it difficult to vendor the code for std.Io.Writer.print, suitably modified to accept a format string at runtime. It should represent only a small amount of effort relative to what this collection of tools already represents.
I wouldn’t wait around for the standard library to support this natively, because it probably won’t happen. But it doesn’t need to. I was unsatisfied with how std.zig.stringEscape handles string printing, so I wrote something to take care of it, and that was that.
You can probably implement what you want using std.fmt.Alt, or at least the tactic it represents.
i myself havent gotten to writing a whole program in zig yet (i just have a project that compiles to an .so and a test program), but id still use c sprintf in zig i think, thats what translation editors like POEditor support and can highlight any mismatches, but they dont know about zigs syntax