Help with DMD internals

[Manu]

On 21 May 2018 at 15:29, Steven Schveighoffer via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/21/18 6:18 PM, Manu wrote:
>>
>> On 21 May 2018 at 06:10, Steven Schveighoffer via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> On 5/20/18 9:49 PM, Manu wrote:
>>>>
>>>>
>>>> On 20 May 2018 at 17:14, Walter Bright via Digitalmars-d
>
>
>>>>> Yes, and only for delete.
>>>
>>>
>>>
>>> Why? This doesn't make a lot of sense, since delete is freeing the
>>> memory,
>>> it shouldn't matter what state the memory is left in. I would argue that
>>> should only be done in debug mode, and actually, I wonder if some other
>>> kind
>>> of sentinel memory pattern should be written instead.
>>>
>>>>
>>>> destroy() also seems to do it.
>>>>
>>>
>>> Yes, because destroy leaves the memory available for reuse. This is
>>> intentional.
>>
>>
>> It's uninitialised memory though, Wouldn't the same argument you made
>> above also apply?
>
>
> Uninitialized, but allocated and usable. The difference between this and
> delete is that delete is going to unallocate that memory. The next time it's
> allocated, it will be overwritten with an init pattern for the new type.
>
> Basically, in D when you have access to memory, it should be in a valid
> state.

Why is it reasonable to expect that the buffer after `destroy()`
should be 'valid'?
Who's to say that the init state is 'valid'?

Surely it's not reasonable to just start using a class after calling
destroy(), as if it's a newly constructed class?
Surely we should expect that dead buffer is emplaced with a new construction?

> This is a valid usage in D:
>
> struct S
> {
>    this(...) {...}
> }
>
> auto s = S(a, b, c);
> destroy(s);
>
> // s is now a fully initialized S ready to be constructed
> s.__ctor(a, b, c);

And you've demonstrated exactly what I'm saying... there's no need for
destroy() to return initialised memory here. It could return
0xfeeefeee memory or something (for debugging purposes).