[Help Wanted] Zig & Odin

[nicbarker]

I would love for clay to be easily usable from both Zig and Odin. However, there's a major sticking point with both that I don't know how to solve.

The core Element Macros rely on a particular feature of the C preprocessor, specifically "function-like macros" and the ability to pass arbitrary text as an argument to these macros. If you're not familiar with this in C, you can take a look at the definition of any of these macros in clay.h (example) and you'll see that they all follow a general form:

#define CLAY_CONTAINER(id, layoutConfig, children)
    Clay__OpenContainerElement(id, layoutConfig);
    children
    Clay__CloseContainerElement()

You can see that in order to correctly construct the layout hierarchy, child declarations need to preceded by a Clay__Open... and then followed by a Clay__Close.... In clay's use case, these macros allows you to automatically sandwhich child layout elements in the required open / close, by "passing a block as a macro argument" - creating (imo) a very nice developer experience:

CLAY_CONTAINER(id, layout, { // This {} is the "third argument" to the macro
    CLAY_TEXT(id, "Child text", layout);
    CLAY_CONTAINER(id, layout, {
        // ... etc
    });
});

As a result it's not actually possible to "forget" to close these containers and end up with a mismatch or with elements incorrectly parented - this macro syntax functions almost like a form of RAII.

Neither Zig nor Odin support this type of "function-like macro" where arbitrary text can be pasted in.

In Odin's case, it might be possible through some combination of defer and non capturing lambdas to replicate this type of behaviour, but what I'm really looking for is something fool proof - where you don't have to spend time debugging a missing call to Clay__Close..., and I don't have to build debug tools to help you with that 😛

In Zig's case, AFAIK there is even less official support for closures, and just glossing over the docs I can't really think of a way to implement it that wouldn't make layout definition a mess.

Any help or out of the box ideas would be greatly appreciated!