safety model in D

[Don]

Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> I hear what you're saying, but I am not enthusiastic at all about
>> defining and advertising a half-pregnant state. Such a language is the
>> worst of all worlds - it's frustrating to code in yet gives no guarantee
>> to anyone. I don't see this going anywhere interesting. "Yeah, we have
>> safety, and we also have, you know, half safety - it's like only a lap
>> belt of sorts: inconvenient like crap and doesn't really help in an
>> accident." I wouldn't want to code in such a language.
> 
> Basically you're saying that safety is an all or nothing deal.  Not only
> is this in direct contradiction to the attempts to allow both safe and
> unsafe modules to coexist in the same program, it is in contradiction
> with all existing programming languages, every single one of which
> offers some safety features but not absolute 100% safety.
> 
> If you have a formal definition of safety, please post it.  Without such
> a definition, I will use my own informal definition of safety for the
> rest of this post: "a safety feature is a language feature that reduces
> programming errors."
> 
> First, to demonstrate that all programming languages in existence offer
> some safety features.  With some esoteric exceptions (whitespace, hq9+),
> all programming languages have a syntax with some level of redundancy.
> This allows the language implementation to reject some inputs as
> syntactically incorrect.  A redundant syntax is a safety feature.
> 
> Another example relevant to D: D requires an explicit cast when
> converting an integer to a pointer.  This is another safety feature.
> 
> Now to demonstrate that no language offers 100% safety.  In the
> abstract, no language can guarantee that a program matches the
> programmer's intention.  However, let's look at a more specific form of
> safety: safety from dereferencing dangling pointers.  To guarantee this,
> you would need to guarantee that the compiler never generates faulty
> code that causes the a dangling pointer to be dereferenced.  If the
> program makes any system calls at all, you would also need to guarantee
> that no bugs in the OS cause a dangling pointer to be dereferenced.
> Both of these are clearly impossible.  No language can offer 100% safety.
> 
> Moreover, that safety necessarily reduces convenience is clearly false.
>  This /only/ applies to compile-time checks.  Runtime checks are purely
> an implementation issue.  Even C and assembly can be implemented such
> that all instances of undefined behavior are trapped at runtime.
> 
> Conversely, the performance penalty of safety applies mostly to runtime
> checks.  If extensive testing with these checks turned on fails to
> reveal any bugs, it is entirely reasonable to remove these checks for
> the final release.

I'm in complete agreement with you, Reiner.
What I got from Bartosz' original post was that a large class of bugs 
could be eliminated fairly painlessly via some compile-time checks. It 
seemed to be based on pragmatic concerns. I applauded it. (I may have 
misread it, of course).
Now, things seem to have left pragmatism and got into ideology. Trying 
to eradicate _all_ possible memory corruption bugs is extremely 
difficult in a language like D. I'm not at all convinced that it is 
realistic (ends up too painful to use). It'd be far more reasonable if 
we had non-nullable pointers, for example.

The ideology really scares me, because 'memory safety' covers just one 
class of bug. What everyone wants is to drive the _total_ bug count 
down, and we can improve that dramatically with basic compile-time 
checks. But demanding 100% memory safety has a horrible cost-benefit 
tradeoff. It seems like a major undertaking.

And I doubt it would convince anyone, anyway. To really guarantee memory 
safety, you need a bug-free compiler...