[skywal_l]

I fail to see how this is a problem. The compiler ensured that the compiled code will always work.

And if you put that in you API and someone call foo with an odd perfect number, well it will fail to compile.

It's conditional compilation, exactly what C does with macros. Except here, you don't have to learn an awful and honestly, sometimes, incomprehensible parallel language.

Zig has some shortcomings but I fail to see how this is one.

[foldr]

It's not the end of the world, but there are significant disadvantages. For example, it makes it difficult for generic libraries to expose stable interfaces. The interface is 'use any type that doesn't make this exact implementation break', rather than (e.g.) 'use any type that implements these traits'. So you could potentially upgrade from v1.0.0 to v1.0.1 of a library and find that instantiating a generic function with a particular type no longer compiles. If you want to know why it doesn't compile, you'll just have to dig into the implementation of the library.

[skywal_l]

Ok I get you. The absence of traits (or concept) make documentation and reading the API harder. You see a `comptime T` somewhere and you don't what is expected of this type unless you either read the code in full or just try your type and see if it compiles.

That's a valid point indeed and there's an issue for that: https://github.com/ziglang/zig/issues/1268