Safety, undefined behavior, @safe, @trusted

[grauzone]

Walter Bright wrote:
> grauzone wrote:
>> Walter Bright wrote:
>>> grauzone wrote:
>>>> If you mean memory safety, then yes and will probably forever be for 
>>>> all practical uses (unless D gets implemented on a Java or .net like 
>>>> VM).
>>>
>>> A VM is neither necessary nor sufficient to make a language memory 
>>> safe. It's all in the semantics of the language.
>>
>> Yes, but VM bytecode is a much smaller language than D, which makes it 
>> far easier to verify for safety. In practice, SafeD will gradually 
>> become actually safe as people use it, see it break, and you fix the 
>> bugs. That's why I said for "all practical uses".
> 
> The Java VM didn't start out as completely safe, either, as people found 
> the holes they were fixed.

Because the bytecode language is much smaller than a high level language 
like D, it's easier for Java. Also, Java was planned to be safe right 
from the beginning, while SafeD is a rather unnatural feature added on 
the top of a complex existing language. To make it safe, you need to 
forbid a set of features, which inconveniences the programmer and will 
possibly reduce code efficiency. I'm not even opposed to the idea of 
SafeD, I'm just worrying that forcing all D code to adhere to SafeD by 
default will cause more trouble than gain.