safety model in D

[Rainer Deyke]

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.


-- 
Rainer Deyke - rainerd at eldwood.com