Tail pad optimization, cache friendlyness and C++ interrop

[Maxim Fomin via Digitalmars-d]

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.