✨Zig文件是一个struct

[Anglebase]

奇怪的语法

为什么Zig要采用这种看起来十分奇怪的包导入语法？

const std = @import("std");

Zig的设计

深入研究了我发现，Zig的文件就是一个struct，所以，以下代码在Zig中是合法的

const std = @import("std");

hello: [14:0]u8 = "Hello, world!\n".*, // What?

fn print(self: @This()) void {
    std.debug.print("{s}", .{self.hello});
}

pub fn main() void {
    const this = @This(){};
    this.print();
}

这段代码为当前文件所代表的struct定义了一个名为hello的字段，并成功地实例化了自己。

这就说的通了，包导入不是在导包，而是在定义一个类型，可以近似理解成：

const std = struct {
    @cInclude("std.zig")
};

不过Zig没有预处理器，不允许文件直接包含的这种写法

所以

Zig并不存在实质上的包导入语法，而是创造了一个由外部文件定义的类型

[jiacai2050]

It's a feature, not bug 😎

[Anglebase]

这确实是个特性🤠，我知道的有标准库的Allocator实现就利用了这一特性单独放在了一个文件里

[jiacai2050]

太多了，只要文件名是大写的，都表示类型。

[htqx]

文档有说这个。整个文件就是构成一个类型。
虽然不知道这样做有啥好处，但把整个文件视为一个巨大的struct就得了

[npc1054657282]

因为zig的包括struct在内的容器类型，原生被设计为命名空间。因此没有字段的struct就可以当成普通的命名空间使用。
而文件被认为是命名空间，既然是命名空间，那就是struct吧！
而struct是允许带字段的。如果文件被禁止带字段，那就相当于“文件是一种特殊的，不允许带字段的struct”，那相当于额外多了一个规则，有必要加这条规则吗？好像没必要，相比增加一个文件是特殊的不允许带字段的struct规则，不如直接允许文件带字段得了。

但个人认为“文件是命名空间”的设计正在受到挑战。这是因为对于命名空间，目前的主流认知是“命名空间用于消除歧义，而不应该用来分门别类”，一个命名空间下的多个相互之间不存在歧义但是分类上有差别的符号，被认为不应该用命名空间对它们进行分类而应该在同一命名空间下平铺。但是，习惯上我们不会使用一个超大的平铺的文件，因此实际上仍然会将这些符号以某种分类放到不同文件中。这就引起了摩擦，如果我们认为文件是命名空间，或者用一个超大的文件平铺收纳这些符号，或者让符号通过命名空间进行层级分类。Odin一类的某些语言的设计中目录是命名空间单元，同一目录下的多个文件之间可以直接相互引用符号。