I bet they wouldn't. They're well aware their complier often runs code inside if(false) blocks (in certain positions) and they just don't see this as important. Moving fast is more important. (Where exactly they're moving to is not quite clear.)
If you look at the issue in question you'll see that it's not a bug, but a proposal to change the semantics of the language; rules about when something is comptime-known or not. If you replace `@compileError` (comptime effect) with `std.debug.print` (runtime effect) the print statement is never reached.
Your claim is false.
Do you have an example? Sounds like a catastrophic edge case.
* 10349: already fixed in master branch; issue remains open until we add behavior test coverage for it.
* 9810: same
* 8952: same
* 4491: same
* 3882: same
* 5230: same
* 6444: duplicate of 5230
* 7097: duplicate of 5230
I went through 100% of your links and 100% of them are solved already. The only reason they are open is because we are being responsible and not closing them until we have verified that each and every case has behavior test coverage.
If zig was being developed using a process where correctness mattered one jot, then the underlying issue wouldn't have kept happening and you wouldn't have kept papering over a fundamentally wrong model. While I did not compare zig to V, now that you brought it up in a related comment, you're right, they do seem to follow very similar development models: "That's not an issue, and even if it is an issue, we've already fixed it, and even if we haven't fixed it, it doesn't matter, and even if it matters, it's not our job, and even if it is, you can't prove it." Wow.
Zig is a toy language with a broken implementation. The comptime story is incoherent; it is two entirely unalike languages being written with superficially similar (but not identical) syntax, and lots of bugs in the gaps. At least V is honest about what it is and isn't.
ETA: I provided links, do you have any evidence whatsoever that any of these issues have been fixed? Because I went through these links and 0% of them have commits attached. 0% of them have comments from a developer indicating they've been fixed (other than comments posted after I shared links). 0% of them have comments from a developer saying that they're being held open in order for testcases to be added. Your claims are just more confabulation from a confirmed liar.
All software with any amount of complexity has bugs, even if there’s a published spec ratified by comittee over the course of 20 years, or whatever your unattainable standard of quality is.
Zig is free software and a community in the best sense of both.
Show some respect.
And I do obviously know who I was interacting with; Kelley's arrogance and lies are legendary (second only to the V devs, but he appears to be consciously competing with them). It drove me away from the language when my own filed bug on this issue was met with a similar response.
> Zig has known bugs and even some miscompilations.
> Zig is immature. Even with Zig 0.9.0, working on a non-trivial project using Zig will likely require participating in the development process.
I don't know why you have it out for me. But as long as your HN account isn't blocked by mods for trolling I'm stuck endlessly refuting your claims.
If you have a language or project as complex as Zig and can provide Andrew with some sort of guidance on better implementation / OSS issue management, I would love to see this. Otherwise, I would encourage you to not post comments criticizing work which you're not qualified to criticize.