Why should @inComptime not be used for e.g. improving compilerrors?

After seeing a bunch of redundant issues, I decided to make a pr which was intended to inform a user that the behaveior they’re witnessing is not a bug to avoid further issues. Andrew, however, turned it down, referring to the fact that, as pointed out in the @inComptime docs, it says, that it shouldn’t be used for such purposes.
Not wanting to waste more of his time, I decided to ask here, what the reason for that may be.

I think in this particular case the existing compile error was already sufficient, as it said it couldn’t be executed at compile time and the call trace showed which functions were being called.

The std module could start adding extra code/checks to provide more concise error messages for particular cases, however if you set this precedent I believe the std module could start to become much larger and filled with these types of checks/error messages which litter the code. Instead it would be both more valuable and leave the std module cleaner if the compiler itself is improved. The compiler already has all the information needed to provide a nice error message here. We can ask ourselves what is it about the current output that is not working for people? We can reach out to those that reported issues and see what confused them. The output contains all the needed information, but why were multiple issues filed around it? Maybe the output has already been improved and those issues wouldn’t have been filed today? The compiler output may also not be the right place to fix this, rather, the tools around the compiler may be the right place. I’ve talked with Andrew about this and his thoughts were that the compiler at least for now should focus on providing ALL the relevant information rather than trying to organize it. Maybe it’s editors/IDEs that should focus on organizing it…or maybe even just a cmdline wrapper tool around the compiler. Note Andrews thoughts here can easily change, he’s operating on the NULL hypothesis which in this case means we shouldn’t do extra work/add features unless the evidence shows it to be a net win.

I’d also add that this stuff is hard. We’re all coming at this with different experiences/opinions/biases. I’ve spent a lot of time reading things from Andrew and in my opinion he’s very thoughtful/intentional and has good reasons for his decisions, but, if he decided to explain his full reasoning all the time I don’t think there’s be any time left to actually work on the compiler :slight_smile:

Anyway those are my thoughts, hope it’s helpful. I understand it can be frustrating to not get answers, there’s so much to do and so little time.

4 Likes

if he decided to explain his full reasoning all the time I don’t think there’s be any time left to actually work on the compiler :slight_smile:

This is why I decided to ask here, I love the language and I know he’s a busy man so I didn’t wanna waste more of his time.

We’re all coming at this with different experiences/opinions/biases.

I actually agree with you, I think many people also made these issues because of the bias that there may be more errors in zig? This isn’t a bad thing, it’s just… a thing. I imagine noone who would’ve encountered something equivalent to this in e.g. Java also wouldn’t have opened an issue for this specific reason, because they would just assume that it’s correct and that they’re wrong.

I think that the fact that I had encountered this issue myself before and didn’t know why it didn’t work + the fact that I am aware that the zig std lib isn’t bug-free yet ended but up making me open that pr.

I do still think that it’s strange to explicitly state the intention of the @inComptime builtin like this in documentation, though. I get the idea, but I think the average user who didn’t read it may end up at some point writing what I wrote myself there. I don’t have a better Idea to enforce that guideline though.

Andrewrk if you’re reading this, I hope I wasn’t too annoying, I think I better understand by now.

1 Like