In Zig’s standard naming convention (and in many places in std) there is a clear structure:
StructNamein the declaration of a structstruct_name(or similar lowercase) in usage of that struct
A capitalized CamelCase name signals a type, while the lowercase form signals a value.
For example, inconsistencies like this appear (LSP data):
fn parse(gpa: Allocator, source: [:0]const u8, mode: Mode) Allocator.Error!Ast
(fn (Allocator, [:0]const u8, Mode) error{OutOfMemory}!Ast)
// Go to Allocator | Mode | Ast
// Result should be freed with tree.deinit() when there are
// no more references to any of the tokens or nodes.
or this (LSP data):
fn deinit(tree: *Ast, gpa: Allocator) void
// (fn (*Ast, Allocator) void)
// Go to Ast | Allocator
Here the returned type is Ast, but the documentation refers to it as tree without ever stating that this is just a local variable name choice.
In effect, this part of std implicitly treats tree as the canonical name for an Ast value, without explaining why.
This is workable because “AST” is well known to stand for “Abstract Syntax Tree”, but in how Zig usually wants things named, it feels more natural to write ast than tree.
User code examples:
// What std want
const tree = try std.zig.Ast.parse(alloc, file_data, .zig);
// What I see as more in line with zig naming convention
const ast = try std.zig.Ast.parse(alloc, file_data, .zig);
This is not just a simple change from tree to ast, since large parts of std here assume that tree is the better name.
Questions:
- Have I misunderstood how Zig naming structure should work, or is this one of the inconsistencies in
std? - I don’t think this is the only place where this happens in
std. Should this be accepted as-is, or should there be a unification where possible, so that local variable usage of a struct inherits its type name (e.g.Ast→ast), at least in function signatures and documentation comments?