typesanitizer

> being able to reason about functions just from their type signature. This has nothing to do with compile-time execution, though. You can reason about a function from its declaration if it has a clear logical purpose, is well named, and has well named parameters. You can consider any part of a parameter the programmer can specify as part of the name, including label, type name, etc. > There is a good discussion of some issues here: https://typesanitizer.com/blog/zig-generics.html That's actually not a great article. While I agree with the conclusion stated in the title, it's a kind of "debate team" approach to argumentation which tries to win points rather than make meaningful arguments. The better way to frame the debate is flexibility vs complexity. A fixed function generics system in a language is simpler (if well designed) than a programmable one, but less flexible. The more flexibility you give a generics system, the more complex it becomes, and the closer it becomes to a programming language in its own right. The nice thing about zig's approach is that the meta-programming language is practically the same thing as the regular programming language (which, itself, is a simple language). That minimizes the incremental complexity cost. It does introduce an extra complexity though: it's harder for the programmer to keep straight what code is executing at compile time vs runtime because the code is interleaved and the context clues are minimal. I wonder if a "comptime…

How do you typecheck generics, with type inference, with comptime? Or, more generally, address all the issues raised in [1]. You're saying that comptime can fully replicate all the features that a proper generics system has, which is plainly false. [1]: https://typesanitizer.com/blog/zig-generics.html

Zig comptime is a C++ template done better. It also suffers from similar issues as C++ templates. You can't know function is comptime unless you put it in comptime and it passes. See https://typesanitizer.com/blog/zig-generics.html

in the "closing thoughts" [1] of the OP article there's a pointer to "Proebstrings law" [2] which got me to a benchmark [3] how LLVM has improved over 10 years from 2.7 to 11 which leaves me with the strong intuition that indeed what mit benefit more from a rethink is not optimizers but focus on programmer productivity > Perhaps this means Programming Language Research should be concentrating on something other than optimizations. Perhaps programmer productivity is a more fruitful arena. [1] https://typesanitizer.com/blog/rethink-optimizers.html#closing-thought… [2] https://proebsting.cs.arizona.edu/law.html [3] https://zeux.io/2022/01/08/on-proebstings-law/

It would be nice to have a more indepth discussion of the issues that have been found with compile-time programming, rather than uncritical acclaim. Staged programming is not new, and people have run into many issues and design tradeoffs in that time. (E.g. the same stuff has been done in Lisps for decades, though most Lisps don't have a type system, which makes things a bit more complicated.) Some of the issues that come to mind: * Implementing generics in this way breaks parametricity. Simply put, parametricity means being able to reason about functions just from their type signature. You can't do this when the function can do arbitrary computation based on the concrete type a generic type is instantiated with. * It's not clear to me how Zig handles recursive generic types. Generally, type systems are lazy to allow recursion. So I can write something like type Example = Something[Example] (Yes, this is useful.) * Type checking and compile-time computation can interact in interesting ways. Does type checking take place before compile-time code runs, after it runs, or can they be interleaved? Different choices give different trade-offs. It's not clear to me what Zig does and hence what tradeoffs it makes. * The article suggests that compile-time code can generate code (not just values) but doesn't discuss hygiene. There is a good discussion of some issues here: https://typesanitizer.com/blog/zig-generics.html