Tail pad optimization, cache friendlyness and C++ interrop

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Mon Jun 16 06:12:32 PDT 2014


On 06/16/2014 06:49 AM, Walter Bright wrote:
> On 6/15/2014 4:26 PM, Timon Gehr wrote:
>> On 06/16/2014 01:06 AM, Walter Bright wrote:
>>> I don't understand your question. I don't know what is unhelpful about
>>> saying that @safe refers to memory safety.
>>> ...
>>
>> You stated the two to be equivalent earlier, which is impossible.
>
> It is for Java,

No. sun.misc.Unsafe can be used to write memory safe code.

> why should D be different?
>
>
>>> The list is not restricted to syntactic issues.
>> (Yes it is,
>
> No, it is not. For example, assigning an int to a pointer is a semantic
> issue, not a [syntactic] one.
>...

By extension, memory safety is a semantic issue. Since it is 
non-trivial, it is in general not verifiable. (This is Rice's Theorem.)

@safe-ty OTOH is a verifiable property of the program.

> ...
>
>> I'm just trying to find the definition/theorem we do not agree on.
>
> I strongly suggest that you can help by identifying specific issues in
> bugzilla

My point was that no implementation of @safe whatsoever can make it 
_equivalent_ to memory safety (i.e. @safe will never single out 
precisely those programs that do not corrupt memory). It will always 
only approximate memory safety. This is not a bug, it's just a fact.

> and marking them with the 'safe' keyword, as I suggested
> earlier.

In my book, the main problem is that @safe is not specified in a way 
that is easy to be verified to guarantee memory safety. I think plugging 
holes one after another as they are discovered in real code  until 
_hopefully_ none remain is not a very productive use of time. We should 
strive to keep @safe sound during its whole implementation.

> I do not believe that memory safety is a difficult concept to
> agree on.
>

Why? Many superficially simple informal concepts are difficult to agree 
on. In this case this is witnessed by the fact that you do not seem to 
want to ban undefined behaviour from @safe code which I can't agree with.


More information about the Digitalmars-d mailing list