Tail pad optimization, cache friendlyness and C++ interrop

[deadalnix via Digitalmars-d]

On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 17 June 2014 at 22:44:00 UTC, Timon Gehr wrote:
>> As you know this will not single out _exactly_ the subset of 
>> programs which is memory safe which is the claim I was arguing 
>> against,
>
> It will single out exactly the programs that are most certainly 
> memory safe, and also single out those programs that have 
> generated unsafe features (instructions). Whether those unsafe 
> features sit in a basic block that will never called is a 
> different matter since @safe does not address that.
>
> So yes, @safe is not equivalent to memory safety, it is 
> equivalent to the absence of FEATURES that can lead to 
> situations that aren't memory safe. But that is splitting hairs.
>

That isn't splitting hair. You are loosing track of the big 
picture here. To come back to the original problem :

memset(&foo, 0, typeof(foo).sizeof);

Walter mention that this is not corrupting memory and therefore 
@safe. In the situation of tail pad optimization, it is obviously 
not valid anymore and will cause memory corruption. The 
discussion then derailed to what is @safe, as the code is 
certainly @safe, but it is difficult to prove it is 
automatically) and the fact that @safe is defined backward (ie by 
listing what is not allowed and adding to the list when new holes 
are discovered rather than listing what is allowed and adding to 
the list when some construct are proven to be @safe).