Hacker News new | past | comments | ask | show | jobs | submit login

There's a push-and-pull on this in D, too. For example, sometimes I want a backtrace at a certain point, so I'll add an `assert(0);` there. The compiler complains that the rest of the code is unreachable. I then have to block out the code with a `static if (0) { ... }`, or comment it out, which is annoying.

But most everyone else likes this, so it stays in.

There are no real right answers here. Adding a switch for it just brings its own annoyance (every compiler switch is a bug). You just wind up settling for a local optimum.




> every compiler switch is a bug

I totally get where this is coming from, but on the other hand it seems like Rust and Zig both get a lot of value from having the compiler understand the difference between debug and release modes, and it seems like modern C++ suffers somewhat from not having any built-in way to do something similar. The optimal number of compiler switches might not be zero.


D literally has the switches `-release` and `-debug`.


It seems to me that a possible improvement would be for the compiler to error on unreachable code in `-release` and to warn in `-debug`.


Why don’t you fix those bugs?


-release is in there for magazine journalists who run benchmarks. -debug is for project managers to bring order to special debug code.


Nearly everyone I speak to hates the unreachable error messages, by the way.

It's not useless to have them but they can be utterly infuriating for exactly the reason you mention since most projects have warnings-are-errors turned on.

The way I shut it up in a class is usually by branching on the this pointer. Sneaky.


Have you considered adding a dedicated `breakpoint` keyword for this use case? Linters could ignore it, but the compiler could warn or error. The problem with workarounds like `assert(0)` is that the linter lacks context to do the right thing.


Adding another feature is always tempting, and there are daily new feature requests for D.

We simply have to have a very high bar for new features.


It's a good principle to pursue. But additional language features for production codebases vs toolchain features that happen to lean on changes to the language as a matter of UI are worth considering separately.


Doesn't D have a debugger? Hitting F9 then F5 sounds a lot faster than fiddling around with the code, hoping that you forget to remove the assert before you go home and that you won't spend time pleasing the compiler.


Yes, gdb. I don't particularly like gdb, though.

> hoping that you forget to remove the assert

I routinely add a lot of instrumentation when developing code. I use `git diff` to remove it before committing.

The compiler builds itself fast enough that this is not a problem. I have one window on the source, the other on the build.


In Virgil I usually do "var x = 1/0;", but there's a command-line option "-fatal-calls=<method glob>", so you can crash on a call to a specific set of methods and get a stacktrace.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: