On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:
On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but
not @safe does not
imply not memory safe.
@safe in D == memory safe.
Why? I found dozens of cases when @safe is broken, let alone
other issues in bugzilla.
After thinking about the @safety in D my conclusion is that it is
impossible to evaluate memory and safety correctness of a code in
which static type says nothing about where an object is
allocated. Contrary to popular wisdom, one can have fixed array
on heaps, classes on stack, etc. If any code which is potentially
not safe is rejected, this would lead to lots of false positives
making using the language very inconvenient. Even in that case,
safety cannot be guaranteed by the language due to other issues,
like separate compilation, etc. By the way, memory safety is also
compromised by compiler bugs which make him generate buggy code.
Note, when I counted memory safety problems, codegen issues were
not counted.
@safe should not be considered as feature which ensures that the
code is memory safe, but as a feature rejecting code with high
probability of memory bugs. The difference is very important.
I have reached this conclusion some years ago and nothing has
change in D since then which make me reconsidering my opinion
(including that @safe holes were not fixed).
Note, that I do not critique the language, it is fine. It is very
good system level language with powerful modelling features. It
is not good at verifying memory correctness, because in such
languages (unlike managed ones) burden of memory correctness lies
mostly on programmer. If he thinks that he can outsource memory
correctness to @safe, there is high probability that he would be
suddenly surprised.
