{json, zon, yaml, ziggy, etc} files versus structured consts in zig for configuration

assuming i do NOT have any interoperability requirements with upstream tooling that produces (say) a .json file, wouldn’t it be best to express “configuration values” as a const struct that i can simply @import into my zig program???

other than some “syntactic niceties”, what’s the advantage of a .zon file over expressing that information as a pub const within some .zig file???  (yes, i know this is currently part of the build system – but the question still stands…)

my current (non-zig) build flow has a mix of {json,yaml,properties} files that contain a variety of “constants” that effectively shape the build flow as well as the final program executable… said another way, i want the contents of these files to become comptime values within zig

a very quick read of std.json suggests that i can parse a json file into a comptime type value… but if i wanted to be “zig all the way down”, presumably i could have captured the same information by declaring a pub const ???

I think one of the advantages is that it is a more strict subset of what is allowed in Zig, so it is useful for cases where potentially other eco systems have a need to be able to read it.

Best depends on your use case, in the future zon will also be importable via @import there is an issue that talks about implementing that. Regarding json etc. for those, you always could define a build step that reads it and for example generates a module that then can be imported from that.

I haven’t used json with Zig enough, but I think you are better off using a build step than trying to use json at comptime, but maybe I misunderstand what you really want to do here. I think a code example would help, if you think that path should be explored.