safety model in D

[Michal Minich]

Hello 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...
> 

I don't know how this could have anything with ideology? Are Java and C# 
ideological languages ? Certainly - if you see memory safety as ideology 
- you cannot escape form it in  these languages. 

Currently in D exist pure functions, but you are not obliged o used them. 
I think the memory safety should be handled the same way, mark a function 
safe, if you want/need to restrict yourself to this style of coding.  And 
just don't use it if you don't need, or cant -same as pure and nothrow. 

Notice that if you code your function safe, it would have only one negative 
impact on the caller - runtime bounds checking. I Admit it is not good. There 
are good reasons to require speed. As the standard libraries would use safe 
code - I'm not sure if it would be required to distribute two versions of 
.lib one with bounds checked safe code and one without bound checking on 
safe code?

I think what concerns you is also how safety would affect use of D statements 
and expression, that it would be too difficult/awkward to use; I don't know 
exactly, but imagine it to be simpler - just like Java/C#(?)

I there should be memory safety in D, I see no other possibility as to specify 
it per function and provide compiler switch to turn off bounds checking for 
safe code if need. I see it as most flexible for "code writers" and least 
interfering with "code users"; there is no need for trade-off. 

Compiler switch that would magically force safety on some code - would just 
not  compile is no way (and specifying safety per module is too grainy - 
both for code users and writers).

Btw. I think non-nullable pointers are equally important, but I see no prospect 
of them being implemented :(