Consider adding a C API

[vitaut]

There is a well-defined binary interface between top-level functions such as fmt::format and their type-erased counterparts like fmt::vformat. This interface relies only on basic C++ features and should be compatible with C (except for the overload returning std::string obviously). As a result, it may be possible to provide a C API that builds argument lists using _Generic and invokes the type-erased functions.

Unlike the printf family of functions, such an API could be fully type-safe, including for runtime format strings, and would not rely on encoding type information in the format string itself.

This issue is opened to gauge interest. React with a 👍 or another emoji if you would use this.

[dimpase]

might be useful for various FFIs.

[soumik15630m]

Hey I was curious so i prototyped C11 _Generic-based wrapper to check for the type-safe C API.

The design uses a tagged union + _Generic macro to map native C types to a fmt::dynamic_format_arg_store backend. It seems to work well without requiring the user to manually specify types in the format string.

Prototype (C11):

FmtArg args[] = { FMT_MAKE_ARG(42), FMT_MAKE_ARG("World") };
fmt_c_format(buffer, 256, "Hello {} from C! Value: {}", args, 2);

This correctly dispatches int, double, and char* at runtime while preserving buffer safety.......the tagged union is ABI-stable and keeps the C header logic-free- no type leaking

If there is interest, I can clean this up into a PR. It would require a minimal extern "C" bridge TU, without expanding the public C++ API surface.

[vitaut]

If there is interest, I can clean this up into a PR.

Sure, a PR is welcome!

[soumik15630m]

Thanks for welcoming a PR!

I've implemented a working C API using _Generic for type-safe arguments. Before finalizing, I wanted to confirm the architecture since I hit issues trying to use basic_format_arg directly.

Current Implementation (Working)

// C-compatible tagged union
typedef struct {
    FmtType type;  // FMT_INT, FMT_DOUBLE, FMT_STRING, etc.
    union { int64_t i64; double f64; const char* str; ... } value;
} FmtArg;

// C++ bridge converts to fmt
int fmt_c_format(..., const FmtArg* args, size_t count) {
    fmt::dynamic_format_arg_store<fmt::format_context> store;
    for (size_t i = 0; i < count; ++i) {
        switch (args[i].type) {
            case FMT_INT: store.push_back(args[i].value.i64); break;
            // ...
        }
    }
    return fmt::vformat_to_n(buf, cap, fmt_str, store).size;
}

Features: Type-safe _Generic macros, all C types supported, format specifiers, custom formatters, zero allocations (thread-local store).

• Works and is fully tested
• Adds custom type-erasure layer (translation from FmtArg to fmt's internal format)

Alternative I Explored

Use basic_format_arg directly to avoid the custom tagged union:

extern "C" {
    fmt_c_arg fmt_arg_from_int(int value) {
        return fmt::basic_format_arg<fmt::format_context>(value);
    }
}

Blockers I hit:

1. C linkage error: C2526: C linkage function cannot return C++ class
2. Namespace conflicts: fmt::basic_format_arg vs fmt::v12::basic_format_arg (ambiguous symbol)
3. Template/extern "C" incompatibility: Templates cannot have C linkage

Even with opaque structs in C, the function signatures compiled in C++ mode trigger these errors.

Question

Is there a way to use basic_format_arg directly from C that avoids these linkage/template issues?

Or should I proceed with the custom FmtArg tagged union approach? It works well but adds a translation layer:

C type → FmtArg → dynamic_format_arg_store → vformat

vs ideal:

C type → basic_format_arg → vformat  

I'm ready to submit the PR with the current approach - just wanted to confirm I'm not missing an obvious path to cleaner integration.

[vitaut]

I think your current approach is fine. The only thing I would suggest to change is using a fixed-size array instead of dynamic_format_arg_store and have an upper bound on the number of formatting arguments.

[soumik15630m]

Sure , I will implement these and open a pr

Thanks ...