Hacking-friendly "--sloppy" mode for Zig.

[vi]

As far as I understand, Zig places great emphasis on code maintainability.

Unfortunately, restrictions required for it are at conflict with ease of development, debugging and prototyping.

I suggest to have a special Zig mode that trades code maintainability for short-term ease, ergonimics and speed of hacking. Command-line option may be --sloppy or --devmode or --lax.

Proposed rules for such mode:

• When Zig would have a proper central package repository, the code is syntax-checked without --sloppy as a minimal acceptance test.
• In Zig documentation, books and tutorials, users should be recommended to avoid publishing (or even checking in) --sloppy mode code.
• Normal and sloppy mode choice should not be tangled with LLVM optimisation level, testing, assertion enabledness and other aspects that are typically different between debug in release.
• Additional built-in and library functions may be available. Example: https://github.com/ziglang/zig/issues/3296
• Errors about unreachable code (and similar), as well as other non-critical errors are downgraded to warnings. Such warnings may be hidden. Similar for ignoring errors, missing switch cases and so on.
• A warning may be emitted just for mere enabling --sloppy mode, as an eye sore reminding that it is not supposed to be permanently enabled.
• Mere turning on --sloppy without modifying source code should not affect program behaviour.
• Comptime functions may check for sloppy mode and @compileError if it is not enabled. The reverse should not be idiomatic.
• Sloppy-only functions and language features are not considered part of Zig. They may be removed / changed even after Zig goes 1.0.0.
• Stable, official versions of Zig compiler may omit support of --sloppy mode. Master builds may be required.

[josephg]

Thanks - I just figured that out. (It took me a lot of searching to realise that was an option - it would be great if the compiler error suggested that as a fix).

the first is done automatically by ZLS' autosave feature

.. But, this is the worst of all worlds as far as this error goes. It means that I don't even get a compiler warning when I have unused variables. My code is silently "corrected" regardless of whether or not the fix matches my intent. If you're going to autofix code to suppress this error, zig may as well just turn the error off entirely.

[rohlem]

My code is silently "corrected" regardless of whether or not the fix matches my intent. If you're going to autofix code to suppress this error, zig may as well just turn the error off entirely.

@josephg Just to clarify, this is the reason why the Zig (core) toolchain has so-far taken a stance against automatic edits. The mentioned "autofix" mechanism is an opt-in feature (configuration setting enable_autofix) of ZLS (which is community-maintained). (I would assume the intent was that people would either immediately spot the autofixes, or re-read code after writing it to look for unintended uses of _ - I don't use it myself, so can't comment on efficiency one way or the other.)

[josephg]

or re-read code after writing it to look for unintended uses of _

This is significantly worse than a compiler warning, but I can see how it ended up this way if zls is community maintained and has a different opinion about this issue than the zig compiler authors. Sorry for temporarily hijacking the thread - and thanks for the advice. I'll give that a whirl.