Tail pad optimization, cache friendlyness and C++ interrop

[Timon Gehr via Digitalmars-d]

On 06/15/2014 08:44 PM, Walter Bright wrote:
> On 6/15/2014 2:48 AM, Timon Gehr wrote:
>> 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
>>  ...
>>
>>> 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.
>
>
> I don't know why the documentation says that. D's @safe is about memory
> safety, not undefined behavior.
> ...

Note that this is frustratingly unhelpful for deciphering your point 
about "memory safe" <=> "verifiably @safe" by definition. Are you 
defining "memory safe" or "verifiably @safe"?

> Note that the list of eschewed behaviors are possibly memory corrupting.

It is an incomplete list. I'd rather see an incomplete list of _allowed_ 
behaviours instead of an incomplete list of eschewed behaviours. In any 
case, I don't see how any list of (syntactic) verifiable properties of 
the code is supposed to be equivalent to the (non-trivial semantic) 
memory safety property. Are you assuming @trusted as an oracle for 
memory safety and saying @trusted code is 'verifiably @safe' code? 
(That's not the intended reading.)

> Signed integer overflow, for example, is not listed.
>

Are you trying to say that signed integer overflow is undefined 
behaviour in D?  (This would again contradict the documentation.)