3 ms·
Because all the semantics for what are the valid parameters for types and other comptime operations are scattered throughout the code that is run at comptime. I
by jibalt 5y ago
Because all the semantics for what are the valid parameters for types and other comptime operations are scattered throughout the code that is run at comptime. It's the same problem as with C++ template code, but perhaps worse. For instance, if you do a formatted print and pass an integer to a "{s}" descriptor, the std.fmt code calls @compileError with an informative message, then a dozen lines of stack trace are printed before a line that shows the source code line that invoked the print, and then yet another stack trace because std.fmt returns an error. And that's for std.fmt that is well behaved and calls @compileError when it should ... in many cases the error will be due to a type mismatch or invoking a non-existent member, etc.
- naasking 5y agoI'm still not quite seeing the problem. To my mind, comptime parameters have a direct translation to parametric type parameters in something like system F or a similar parametrically polymorphic type system, and reasonable type errors are possible in those. Do Zig's comptime parameters universally violate parametricity in some way, and this is why the errors are more difficult?