Orthogonal "Release optimization target" and "Runtime safety"

[ghost]

This proposal is about a more flexible and transparent alternative to existing build modes: debug, release-fast, release-small, and release-safe.

The idea is to make "optimization target" and "runtime safety" into orthogonal features.

Optimization target for the binary then becomes either "performance", "fastbuild", or "smallsize". Runtime safety is a separate concern.

Runtime safety checks would be enabled on an individual basis in each build.

in buildscript:

setBinaryOptimization(OptimizationTarget.Fastbuild);

enableCheck(RuntimeSafety.Overflow);
enableCheck(RuntimeSafety.DivideByZero);
enableCheck(RuntimeSafety.....);
//....

safetyLevel = 50; // percentage or threshold for userland runtime checks

in userland code:

//comptime evaluated!
if(getRuntimeSafetyLevel() >= 50){
	assert(....)
}

// std could offer some percentage value "constants" for standardization purposes
if(getRuntimeSafetyLevel() >= Safety.MEDIUM){
	// do safety check
}


if(getRuntimeSafetyLevel() >= Safety.HIGHEST){
	// do complex data integrity test here
	// when safety level is high, can catch bugs 
	// when safety level is lower, still serves as documentation
}

This would IMO be very transparent and understandable for the user, vs having to read about the different build modes in the docs.

Related: #978

[Tetralux]

Being able to set optimization level, debug info, debug info type, bounds checks, cast checks etc, on/off on a per-item basis could be useful. I'm not sure about percentages though.

[FlyingWombat]

Instead of enableCheck, how about disableCheck in the build-script to follow Rust's "safety by default" idea? There could also be a compiler option like --safety-off=all for disabling all safety checks for that build.

For program code, how about disabling specific checks for blocks of code with unsafe(Safety.Overflow) { ... }?