Tail pad optimization, cache friendlyness and C++ interrop

[Timon Gehr via Digitalmars-d]

On 06/15/2014 10:33 AM, Walter Bright wrote:
>>
>> What Timon is saying is that not all memory safe code is verifiably
>> @safe.
>
> In D, they are defined to be the same thing,

Since when?

http://dlang.org/function

"Function Safety

Safe functions are functions that are _statically checked_ to exhibit 
_no possibility of undefined behavior_. Undefined behavior is often used 
as a vector for malicious attacks.

Safe Functions

Safe functions are marked with the @safe attribute.

The following operations are not allowed in safe functions:"

I.e. the documentation has two (conflicting) definitions and none of 
them is the one you claim there is.

> so the statement makes no sense.

Then please indicate how to fix the documentation. If you are going to 
claim the Humpty Dumpty privilege, I'll back off. Thanks.

On 06/11/2014 11:35 AM, Walter Bright wrote:
> What's not provable? Why would bit copying a struct not be memory safe?

Since you claim memory safe is the same as verifiably @safe, you are asking:

> What's not provable? Why would bit copying a struct not be verifiably @safe?

struct S{ int x; }

void main()@safe{
     S s,t;
     memcpy(&s,&t,S.sizeof); // error
}

So, what is it that you are trying to bring across?