On 21 May 2018 at 15:51, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 5/21/18 6:37 PM, Manu wrote: >> >> On 21 May 2018 at 15:29, Steven Schveighoffer via Digitalmars-d >> <digitalmars-d@puremagic.com> wrote: >>> >>> 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'? > > > It's valid in that it's not garbage, and that it's not full of dangling > pointers.
Ah! Dangling pointers... that might conservatively retain garbage. That's a good reason. >> 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). > > > No, the ctor assumes all values are in init state. If that's not the case, > then the code will crash or corrupt memory. ...so, assign init immediately before construction? Rather than assigning init on destruction, which makes destroy more expensive, and it may or may not be re-used (most likely not). Why isn't assigning init built into the constructor?
