Justwerk compiler flag

[Dukc]

On Thursday, 17 July 2025 at 16:28:25 UTC, monkyyy wrote:
> Failing to parse is different from not working because extra 
> code decides its a bad idea; my line would be mostly ()'s 
> matching and semicolons for *compiled* *c-like* languages;

If you want a language that rejects pretty much only syntax 
errors and nothing else, Forth might be what you want, being 
typeless by default.

However, D isn't and does not try to be that kind of a langauge. 
It is explicitly the purpose of it's type system to not only add 
expressive power, but also guard against errors when you want it 
to. Same with most other languages too, although it varies how 
low/high they let you to set the guard rails.

It is certainly fun when you can do all sorts of tricks with the 
language, but sometimes you want to be careful with what you 
make, or just get fed up with hunting down your own bugs. In 
those cases, it's nice if your language has mechanisms to prevent 
errors. D tries to give you the guard rails when you want them, 
but also to remove them when you don't want them.

In the case of `@safe` and `private`, can't you simply not use 
them when they get in the way? Mark your function `@system`, and 
bye bye safety checks. If someone else marks a struct or class 
field private and you want to use it, `.tupleof` does the trick. 
Well, if it is a private function or global variable, then I'm 
not sure there is a way, but I would rather have D solve it by 
some module-level equivalent to `.tupleof` rather than a compiler 
switch, if it needs solving at all.

As for `immutable`, there could potentially be a case where you 
would want to disable the compiler assumption related to it (NOT 
the type errors from mutating immutables, you can shut those up 
with a cast). You might have some unrelated problem and wish to 
work around it by mutating a string in place, for lack of better 
solutions. Since that is undefined behaviour, a compiler flag to 
disable read-only memory and const/immutable assumptions would be 
what you want.

Still, you could say the about any assumptions the compiler is 
normally allowed to make, such as "ints are not pointers in 
disguise". Are there often problems that the particular hack of 
mutating immutable data would resolve?