[andrepd]

You misunderstand.

> 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

[littlestymaar]

Right, and this should be discussed a lot more when talking about Zig, because I suspect this is going to be a significant burden at the ecosystem level:

- 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)

[usefulcat]

C++ has this problem too, but the funny thing is that I rarely run into it in practice.

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.

[littlestymaar]

> C++ has this problem too

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.

[pjmlp]

I am afraid of being robbed in a dark alley, now in regards to programming languages I never understood what one should be afraid of.

[littlestymaar]

I've fortunately never been robbed in a dark alley and that's not something that sounds like a real threat to me, but I had to intervene on nightmarish code-bases and some “convenient” feature sometime turn to be real curses (JavaScript `with` anyone?).

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.

[Yoric]

Lucky you :)

I used to code in C++ and I had that problem quite often. Including in implementations of the STL.

[verdagon]

I suspect this might not be a problem for Zig long-term. One can imagine a blend of comptime, concepts, and generics which which can help mitigate (and often solve) these kinds of problems. When combined with compiler enforcement (or even a community-adopted linter) this could help the library author detect problems while still being able to use comptime's unique benefits.

[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