grauzone wrote:
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.
On the other hand, Java has had a much larger ambition, i.e. executing
untrusted code in a sandbox, so that balances things a bit.
I may as well be wrong, but my intuition is that there are no
insurmountable holes that would make D unusable for safe programs. I can
clearly see the exact reasons why C++ cannot have a reasonably
well-defined safe subset: you can't do anything of significance in C++
without using pointers and pointer arithmetic. (That could be mitigated
by a library.) Anyhow, here are a few elements that I think contribute
to D's ability to approach memory safety:
* garbage collection
* built-in arrays
* reference semantics for classes
* pass-by-reference (ref)
* safe approach to variadic functions
Without some or all of these, a safe subset of D would be more difficult
to define and less expressive.
Andrei
