>we can't type-check zig libraries which contain generics.
>comptime is_odd_perfect_number(n)
I assume zig has a finite bound on comptime_int, so we can in fact always know what is_odd_perfect_number() returns.
I assume zig has a finite bound on comptime_int, so we can in fact always know what is_odd_perfect_number() returns.
> we can't type-check zig libraries which contain generics. We can only type-check specific uses of those libraries.
I.e. you cannot say whether this compiles for all n, only for the instances you actually instantiate
- library users will find compilation errors in the library code (his is annoying, but when you get used to it, you can treat it as any kind of library bugs and submit a PR)
- library users are going to rely on accidental behaviors (that is “in the library author's mind this isn't been used this way”) and then you'll have breaking changes without noticing.
(I say that as someone currently working on a DSL for the train industry, and this language (started in 2012) has something really close to Zig's comptime and we're currently trying to move away from it, because of the aforementioned issues. And it's actually pretty hard because big chunks of the existing code don't actually compile unconditionally and only compile when a given set of compile-time conditions are met, which makes the migration process hard)
There is a lot of templatized c++ library code out there, yet in everyday practice I find it's very rare that I need to instantiate a template with a type that causes a compile error.
That's true. C++ templates are exactly like that too.
They are a bit arcane though, and many developers are afraid of them and use them very conservatively or even avoid them altogether so maybe this helps mitigate the issue.
Comptime (at least with the language I'm currently working on) are a lot less scary, and people use them quite a lot without thinking too much, so maybe it's the main difference. And I think Zig is closer to this than it is to C++ templates, but I can't be sure since I've never seen people writing Zig code.
Edit: it's late in here, and I completely missed your point. I'm personally not usually afraid with language features, but some requires more work than others to be accustomed to, and not everyone is willing to spend their spare time doing so.
I used to code in C++ and I had that problem quite often. Including in implementations of the STL.
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.
That's a valid point indeed and there's an issue for that: https://github.com/ziglang/zig/issues/1268