22 ms·
A potentially huge roadblock to better error messages is lack of generics and interfaces/traits/classes. The comptime machinery is really cool, but it gives th
by the_duke 5y ago
A potentially huge roadblock to better error messages is lack of generics and interfaces/traits/classes.
The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors.
It'll be interesting to see how this plays out as the ecosystem grows.
- naasking 5y ago> The comptime machinery is really cool, but it gives the compiler much less information to work with for producing good errors. Why do you think that's the case?
- jibalt 5y agoBecause 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?