On Sunday, 21 May 2017 at 14:13:20 UTC, Stanislav Blinov wrote:
> Not if you either emplace() or blit Foo.init into all of the array elements.

You especially need to be safe calling ~this on Foo.init.

On Monday, 22 May 2017 at 00:23:26 UTC, Adam D. Ruppe wrote:
> On Sunday, 21 May 2017 at 14:13:20 UTC, Stanislav Blinov wrote:
>> Not if you either emplace() or blit Foo.init into all of the array elements.
>
> You especially need to be safe calling ~this on Foo.init.

How so? .init is supposed to be destructible without question. destroy() calls in the runtime also blit the initializer back over the destructed objects. std.algorithm.move et al. specifically take advantage of .init (blit it over the moved-from object, so it can either be destructed or assigned something else).

I can't think of any case where you'd want preconditions on destructor when the object is in .init state.

On Monday, 22 May 2017 at 00:36:24 UTC, Stanislav Blinov wrote:
> I can't think of any case where you'd want preconditions on destructor when the object is in .init state.

I think we're actually saying the same thing: I mean the destructor must be callable on .init so you might do like

struct Foo {
   int* ptr;
   ~this() {
      // might be called with ptr is null cuz of .init
      // so wanna check
      if(ptr !is null) free(ptr);
    }
}

On Monday, 22 May 2017 at 00:45:27 UTC, Adam D. Ruppe wrote:
> On Monday, 22 May 2017 at 00:36:24 UTC, Stanislav Blinov wrote:
>> I can't think of any case where you'd want preconditions on destructor when the object is in .init state.
>
> I think we're actually saying the same thing: I mean the destructor must be callable on .init so you might do like
>
> struct Foo {
>    int* ptr;
>    ~this() {
>       // might be called with ptr is null cuz of .init
>       // so wanna check
>       if(ptr !is null) free(ptr);
>     }
> }

Ah, yes, exactly. The page is indeed the same one.

P.S. Though it's fine to call free with a null pointer :P