Tail pad optimization, cache friendlyness and C++ interrop

[Matthias Bentrup via Digitalmars-d]

On Wednesday, 18 June 2014 at 08:13:59 UTC, Walter Bright wrote:
> On 6/18/2014 12:05 AM, deadalnix wrote:
>> On Wednesday, 18 June 2014 at 07:02:43 UTC, Walter Bright 
>> wrote:
>>> On 6/17/2014 11:50 PM, deadalnix wrote:
>>>> 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
>>>
>>> https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=safe%2C%20&keywords_type=allwords&list_id=41168&query_format=advanced
>>>
>>>
>>> Currently, there are zero bugzilla issues tagged with 'safe'. 
>>> Please file
>>> bugzilla issues for which ones are discovered and tag them!
>>
>> I don't even know what to answer to that. We are clearly 
>> talking past each other
>> here, and I have no idea how to convey the message in a better 
>> way.
>
> 1. A long list of problems with @safe has been asserted, but I 
> have not been able to elicit any enumeration of them, so the 
> extent of this problem is completely unknown.
>
> 2. The definition of @safe in the spec is asserted to be 
> utterly wrong, but no corrected definition has been proposed.
>
> 3. A new approach to designing @safe has been proposed in vague 
> terms, but nothing specific and no offers of help to flesh it 
> out.
>
>
> From my perspective, it is like bug reports I'd often get for 
> the compiler that consisted solely of:
>
>     "Your compiler doesn't work."
>
> It's just not helpful. There's nothing I can do with that.
>
> Also, D is a collaborative effort. If there's an issue that 
> engages your interest, step up and help out. I simply cannot do 
> everything. This n.g. is full of "you should do this, you 
> should do that" largely directed at me. You guys want things to 
> happen, make them happen!

You two speak different languages here, I'll try to translate:

Basically deadalnix argues that memory safety cannot be checked 
by a machine (there's a proof for that) and as @safe-ness can be 
checked it obviously is not equivalent to memory safety. Further 
*any* definition of @safe-ness that can be expressed by a finite 
set of mathematical rules will not be equivalent to memory safety.

Then the big misunderstanding is the "equivalence". Equivalence 
means that
   1) @safe implies memory-safe
   2) !@safe implies !memory-safe

Clearly Walter is only talking about 1), and there is no reason 
why you couldn't have a @safe-ness check that implies 
memory-safety. It just won't be *equivalent*.