Type-erased delayed string formatting

Help
1

I want to do something like this:

fn main() !void {
    const f = delayedFormat("foo {}", .{123});
    try doThing(some_writer, &f.interface);
}

// The typical way:
// fn doThing(w: *std.Io.Writer, comptime fmt: []const u8, args: anytype)

// But I want this instead:
fn doThing(w: *std.Io.Writer, f: *DelayedFormat) !void {
    // ...
    try w.print("{f}", .{f});
    // ...
}

Now doThing does not have to be generic, so you won’t bloat the binary if you call it with many different comptime format strings.

Has anyone made a lib for this yet?

2 Likes
2

I can’t remember of any runtime string formatting libraries written in Zig. Could be a cool open source project to work on :^)

As a janky workaround if you link libc you can use printf.

3

Another way to do it would be an alternative to std.Io.Writer.print that still has comptime format string, and still takes a tuple, but is inline and lowers to a call to a non-generic, type-erased function.

Since this has identical function signature, it might even make sense to offer this as an application configuration option in the standard library :thinking:

4 Likes
4

@kristoff I don’t mean runtime strings, I mean a type-erased interface over a (comptime string, args) pair. The same way Thread.Pool makes a type-erased interface over a pair of (comptime function, args).

@andrewrk I’m not convinced that would solve it. I probably didn’t explain it well, but in the snippet I was trying to show that doThing shouldn’t have any knowledge of the format args.

Or to put another way:

fn main() !void {
    const f1 = delayedFormat("foo {}", .{123});
    try doThing(&f1.interface);

    const f2 = delayedFormat("foo {s} {s}", .{"abc", "def"});
    try doThing(&f2.interface);
}

fn doThing(w: *std.Io.Writer, f: *DelayedFormat) !void {
    finalThing(some_writer, f);
}

fn finalThing(w: *std.Io.Writer, f: *DelayedFormat) !void {
    try w.print("{f}", .{f});
}

If I passed the differently-typed arg tuples all the way down to finalThing and print (even with an alternative Writer.print), every function in the call stack between main and finalThing would have to be generic. I want to avoid that.

5

Yes please! We have it on the todo list to implement that for TigerBeetle, as our debug logs add a lot to our binary size.

6

I had actually started something like that but it was on 0.13 and a lot of stuff broke in the meantime, including the comptime logic.

My idea was to have single fn format(tape: []const Fmt , args: []const u8) the caller would pass a pointer to the args tuple, and the function would interpret the bytes based on the “tape” metadata. The “tape” was created at comptime.

Did you have another idea in mind?

At the time I also estimated that 15% of Zig compiler binary was generated fmt functions.

7

I think runtime formatting is definitely something worth investigating but not what the original post is about as far as I can tell.
Perhaps something like this?

1 Like
8

Oh, I just realised that that will definitely fail when closing over other values, that’d need to be considered and put into DelayedFormat as well, should be pretty simple.
Edit: “Should be pretty simple,” I say. Right…

1 Like
9

Main challenge there is coming up with a way to not include, for example, f128 printing code if such thing is not needed.

I can think of a way to do it, but unsure if it’s in poor taste. One idea is to call through a weak extern function that does the rare, expensive printing. This is initialized to null but in the logic that processes the comptime string, if such printing is encountered, it would reference an exported matching function definition.

10

I admittedly haven’t studied how non-generic prints are implemented, but my first thought would be to do just a vtable?

fn dyn_print(items: []const anyopaque, fns: []const fn(*anyopaque)) void

I guess it might make sense to specialize this to popular types like ints, but there’s going to be some dynamic dispatch somewhere to handle {f}, and f128 could go through that machinery?

11

I was in a need for runtime formatting a few times already (and I did what Andrew was suggesting), but I never (so far) needed f128 printing, not even in comptime. Am I missing some common use-case or why is it a thing? IIRC Rust/Go didn’t have formatting for f128 either (maybe they still don’t, I just don’t care anymore).

12

I think he meant how to not include f128 formatting code in program that does not use it. i.e if a program only use {s}, there should not be any code included in for printing ints or floats… So further code size reduction.

13

Yes, I think this would be best of the both worlds. The non-generic runtime version of printing could be used for runtime translations (multi-lingual) stuff as well assuming it still has safety checks between format string and input.