ability to @import .zon files

[andrewrk]

Extracted from #14523.

Given a foo.zon file:

.{
    .bar = "hello",
}

it should be possible to @import it as a comptime-known value:

const data = @import("foo.zon");
comptime {
    assert(std.mem.eql(u8, data.bar, "hello"));
}

One motivating use case in particular is, inside build.zig, one should be able to @import("build.zig.zon") and access those values.

Note that the top level expression of a zon file is not necessarily an anonymous struct literal. It can be:

• string literal
• boolean literal
• integer literal
• null literal
• undefined literal
• anonymous struct literal
• tuple literal
• anonymous enum literal

[f3fora]

"Zig source files are implicitly structs" ziglang.org. Why is this philosophy not followed in the zon ones too?

Given the following snippet with an import for foo.zon

const data = @import("foo.zon");
comptime {
    assert(std.mem.eql(u8, data.bar, "hello"));
}

my expectation for a foo.zon file is

.bar = "hello",

and not

.{
    .bar = "hello",
}

[SidharthRG]

"Zig source files are implicitly structs" ziglang.org. Why is this philosophy not followed in the zon ones too?

This was actually my first thought as well. But then,

.bar = "hello",

likely wouldn't work. It'd have to be written as:

const bar = "hello";

But now we're just writing code in the ZON file, which defeats the purpose of an object notation.

---

As presented so far, it seems like the ZON format is intended to be parsed at compile time for resolving package dependencies. Is runtime parsing in application code also going to be allowed? That would allow ZON files to be used to specify app configs (replace a settings.json, say, with settings.zon).

[ducktype]

Hello, i'm also interested in runtime parsing of zon files!

[InKryption]

This seems to be the only issue I could find in which there is any description of what is allowed in zon files, so I'll ask these questions here:

Zon files are allowed to be, or to contain, zig literals: what about expressions that evaluate to the equivalent of these literals? E.g. is "foo" ++ "bar" allowed as a zon object? Or how about 4 * 1? Or even simpler, is ('a') allowed?

(Similar to the first question) Should &.{} be allowed to describe an empty list, or should .{} be used to describe both empty/defaulted structs and empty lists?.

Do multi-line string literals fall under "string literal"?

In the case of a value being undefined in a zon file, does that mean the imported value will also be treated as regular undefined? Is this safe? How do we handle an undefined value coming from an imported zon file, and how should we detect/know to initialize such a value? It seems sort of like a footgun to me.

[iacore]

Right now, const val: T = <zon here>; is just as good. It also type checks for you.

[jcs090218]

The runtime zon file benefits the most, so I second it. :D

Another question is, can a zon file be empty? If yes, what would it be? An undefined? 🤔

[Arnau478]

Another question is, can a zon file be empty? If yes, what would it be? An undefined? 🤔

Looking at the parsing code, it doesn't seem to allow that, as Ast.parse ends up parsing an expression, and encountering EOF during expression parsing is an error. Plus, I don't see any benefits of having empty zon files. As I said, they're expressions, so if you want it to be undefined you can just create a zon file with undefined on it.

[linusg]

The "retrieve version from build.zig.zon" use case might be addressed by #20510, which exposes it through b.manifest.