.zon and init with .decl_literal

reeFridge · June 27, 2025, 10:42pm

It looks like it is not possible to initialize a struct or tuple field with a .decl_literal in zon files.

How difficult would it be to implement this?

I have just searched through the Zig sources and found that AstGen and ZonGen handle .enum_literal differently. But can we achieve the same behavior as we have in regular .zig files?

github.com/ziglang/zig

lib/std/zig/AstGen.zig

master


      
          },
          .block_two,
          .block_two_semicolon,
          .block,
          .block_semicolon,
          => {
              var buf: [2]Ast.Node.Index = undefined;
              const statements = tree.blockStatements(&buf, node).?;
              return blockExpr(gz, scope, ri, node, statements, .normal);
          },
          .enum_literal => if (try ri.rl.resultType(gz, node)) |res_ty| {
              const str_index = try astgen.identAsString(tree.nodeMainToken(node));
              const res = try gz.addPlNode(.decl_literal, node, Zir.Inst.Field{
                  .lhs = res_ty,
                  .field_name_start = str_index,
              });
              switch (ri.rl) {
                  .discard, .none, .ref => unreachable, // no result type
                  .ty, .coerced_ty => return res, // `decl_literal` does the coercion for us
                  .ref_coerced_ty, .ptr, .inferred_ptr, .destructure => return rvalue(gz, ri, res, node),
              }

github.com/ziglang/zig

lib/std/zig/ZonGen.zig

master


      
                  },
                  else => {},
              }
              try zg.addErrorTok(tree.nodeMainToken(node), "expected number or 'inf' after '-'", .{});
          },
          .number_literal => try zg.numberLiteral(node, node, dest_node, .positive),
          .char_literal => try zg.charLiteral(node, dest_node),
          
          .identifier => try zg.identifier(node, dest_node),
          
          .enum_literal => {
              const str_index = zg.identAsString(tree.nodeMainToken(node)) catch |err| switch (err) {
                  error.BadString => undefined, // doesn't matter, there's an error
                  error.OutOfMemory => |e| return e,
              };
              zg.setNode(dest_node, .{
                  .tag = .enum_literal,
                  .data = @intFromEnum(str_index),
                  .ast_node = node,
              });
          },

milogreg · June 28, 2025, 12:19am

It should be possible to implement this in the parser, but the new logic wouldn’t be in ZonGen, since that doesn’t have access to the type you are parsing it into (an enum literal and a decl literal appear the same if you don’t know what the result type is).

From glancing at std.zon.parse, it looks like it might not be too difficult to support this. The bigger question though is whether this is considered a proper use of ZON. I don’t know much about the exact philosophy behind ZON beyond the fact that it’s meant to parse into zig types, and I don’t think there’s any formal documentation for it yet. If the intention is for ZON to exactly represent the right hand side of an assignment then maybe decl literals will be a supported feature, but my gut tells me that they won’t be supported even if you find a good way to implement it.

vulpesx · June 28, 2025, 5:45am

field and decl names cant conflict so it can just be resolved later when the type is known