Thoughts about D

[Adam D. Ruppe]

On Friday, 1 December 2017 at 04:07:24 UTC, Jonathan M Davis 
wrote:
> It only implies no bounds checking in @system code, though 
> obviously, if you're not marking code with @safe or simply want 
> the bounds checking to be enabled in @system code, then using 
> -release isn't something that you're going to want to do.

Indeed, but disabling bounds checking in @system code is trivial 
anyway (just use `.ptr` in the index expression, and that's the 
level it should be done - individual expressions that you've 
verified somehow already).

> Pretty quickly, it sounds like what -release does isn't 
> appropriate at all

Well, my real point is that -release is too blunt to ever use. 
Every time it is mentioned, my reply is "-release is extremely 
harmful, NEVER use it", since it does far too much stuff at once.

So what I'm asking for here is just independent switches to 
control the other stuff too. Like we used to just have 
`-release`, but now we have `-boundscheck=[on|safeonly|off]`.

I propose we also add `-assert=[throws|c|traps|off]` and 
`-contracts=[on|off]` and perhaps `-invariants=[on|off]` if they 
aren't lumped into contracts.

Of those assert options:

throws = what normal D does now (throw AssertError)
c = what -betterC D does now (call the C runtime assert)
traps = emit the hardware instruction (whether hlt or int 3)
off = what -release D does now (omit entirely, except the 
assert(0) case, which traps)


Then, we can tweak the asserts without also killing D's general 
memory safety victory that bounds checking brings.