safety model in D

[Andrei Alexandrescu]

Leandro Lucarella wrote:
> Andrei Alexandrescu, el  5 de noviembre a las 08:48 me escribiste:
>> First off: _all_ languages except C, C++, and assembler are or at
>> least claim to be safe. All. I mean ALL. Did I mention all? If that
>> was some ideology that is not realistic, is extremely difficult to
>> achieve, and ends up too painful to use, then such theories would be
>> difficult to corroborate with "ALL". Walter and I are in agreement
>> that safety is not difficult to achieve in D and that it would allow
>> a great many good programs to be written.
> 
> I think the problem is the cost. The cost for the programmer (the subset
> of language features it can use is reduced) and the cost for the compiler
> (to increase the subset of language features that can be used, the
> compiler has to be much smarter).
> 
> Most languages have a lot of developers, and can afford making the
> compiler smarter to allow safety with a low cost for the programmer (at
> least when writing code, that cost might be higher performance-wise).

D is already a rich superset of Java. So the cost of making the language 
safe and useful was already absorbed.

> A clear example of this, is not being able to take the address of a local.
> This is too restrictive to be useful, as you pointed in you post about
> having to write static methods because of this. If you can't find
> a workaround for this, I guess safety in D can look a little unrealistic.

Most other languages do not allow taking addresses of locals. Why are 
they realistic and SafeD wouldn't? Just because we know we could do it 
in unsafe D?

> I like the idea of having a safe subset in D, but I think being
> a programming language, *runtime* safety should be *always* a choice for
> the user compiling the code.

Well in that case we need to think again about the command-line options.

> As other said, you can never be 100% sure your program won't blow for
> unknown reasons (it could do that because a bug in the
> compiler/interpreter, or even because a hardware problem), you can just
> try to make it as difficult as possible, but 100% safety doesn't exist.

I understand that stance, but I don't find it useful.

Andrei