之字形皱纹

我正在学习 Zig，到目前为止它看起来很棒。不过，我希望看到一些皱纹被修复，即使它们在宏伟的计划中很小。也就是说，我只包含了至少其他一些人同意的项目是一个问题。 Zig 分配器遵循基于@fieldParentPtr 的巧妙接口习惯用法。虽然灵活，但它可能会导致细微的错误： pub fn init ( allocator : * std . mem . Allocator ) @This () { var instance = MyThing ( T ){ .竞技场 = 标准。堆。竞技场分配器。 init ( 分配器 ), };实例 。项目 = 标准。 ArrayList（项目（T））。 init ( & instance . arena . allocator );返回实例；当 init 返回时，会创建一个副本。 Zig 目前 (0.7.x) 仅在直接返回结构文字时才保证复制省略（感谢 ifreund 指出这一点）。所以本质上 &instance.arena.allocator 现在指向一个临时的，导致内存损坏。一种解决方案是创建一个实例方法（传递 self），但这会使调用站点变得丑陋。在我的特殊情况下，它通过移动到 ArrayListUnmanaged 来解决，其中分配器被传递到每个列表操作。这使得可以删除有问题的 init(&instance.arena.allocator) Zig 循环有时会导致不必要的污染父作用域。这是其他语言中错误的来源。例如，C99 通过允许 for 循环中的 init 子句作为声明来部分修复此问题。 ...但这很快就会变得丑陋，尤其是嵌套。我怀疑人们会经常使用这个习语。

问题是，功能在进化。也许最初没有必要对 i 进行作用域，但是随后您添加了另一个循环，并错误地重用了该变量。这会导致极难发现的错误，特别是如果它发生在很少执行的路径中。 std 库中有一些例子，作者仔细地重新初始化了循环变量，因为在同一级别有多个 while 循环使用相同的变量。这而不是手动确定范围。这是一个在未来更改/重构期间可能出错的示例。一个初始化子句，也许是其中之一（尽管第一个显然不能工作……原因）：我个人更喜欢某种初始化子句。 C++17 甚至对 if, if (init; expr) 也有这种情况，这是只有初学者可能会遇到的事情。我做了，我和 marler8997 讨论了它，他很友好地写了一个问题：https://github.com/ziglang/zig/issues/8012 基本上问题是“静态字段”看起来像实例变量，var x = something;，虽然它们实际上在所有实例之间共享。正如 marler8997 所指出的，您需要犯两个错误才能遇到这种情况，但这对于初学者来说实际上是完全可行的。首先，您进行了命名空间声明（我不清楚技术术语是什么）而不是实例字段。其次，你必须忘记把“自我”。在变量名前面。但是，如果您认为您一直在创建实例变量（这就是它的样子）并且有足够的肌肉记忆在引用“var 声明”时忽略 self，请准备好进行调试会话。

在分层应用程序中，通常有一种明显的方式来传达源自较低层的错误，例如写入日志文件或显示 UI 元素。好的错误信息意味着尽可能多的上下文。哪个文件没有权限？邮件网关失败并显示什么消息？许多语言都有一种根据上下文发出错误的方法，通常是格式化的字符串。 Java 有异常，Rust 有 with_context 等等。Zig 在这里没有提供解决方案，它只是简单的错误联合。这在大多数情况下是有效的，并且足够了，但留给您去设计一个解决方案，以便在需要时传播自定义错误消息。有时这很容易，有时则不然。这为您提供了一个指向 item 的指针，但 * 使它看起来像 items 是一个被取消引用的指针序列（尤其是对 C 程序员） 可以说它反映了一个指针声明，但 item 不是一个类型！我因此认为|&item|更有意义（可能存在我不知道的解析/语义问题）另外，为什么将其称为“通过引用”？引用似乎不是一种语言结构。这只是一个指针，对吧？例如，在expectEqual 中，预期结果是第一个参数，但它是anytype。这导致了大量烦人的文字转换：改变参数顺序，不再需要转换（因为在 expectEqual 的签名中放置了 anytype）

我认为像 150f64 这样的原始后缀可能是一个实用的中间立场。仍然是一个演员，但一个可读的：Lambdas，所以我可以做accumulate(1, list, (a,b) => a*b)，尽管fengb 指出了这个问题，其中闭包捕获超出了范围。某种 vtbl 糖（接口、协议、特征）。对于小部件框架、虚拟文件系统接口和其他类型替换有意义的地方很有用。自己滚动它是可能的，但也很冗长且容易出错。最坏的情况是，如果每个人都推出自己的产品，并且他们不进行组合或互操作。多分派，帮助解决解析器等中经常遇到的表达问题。 Julia 语言已经展示了这种结构的强大和可组合性。选择和取消异步操作。这些是众所周知的缺陷，有望在 1.0 之前得到修复。我希望能够等待一个或所有结果，就像 Javascript 承诺中的 all 和 any 一样。