I have submitted a bug report regarding this:
https://issues.dlang.org/show_bug.cgi?id=17592

This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.

Alex

On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
> I have submitted a bug report regarding this:
> https://issues.dlang.org/show_bug.cgi?id=17592
>
> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>
> Alex

No responses!?

On 07/09/2017 01:27 PM, 12345swordy wrote:
> I have submitted a bug report regarding this:
> https://issues.dlang.org/show_bug.cgi?id=17592
> 
> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
> 
> Alex

Seems related to https://issues.dlang.org/show_bug.cgi?id=17297. -- Andrei

On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:
> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
>> I have submitted a bug report regarding this:
>> https://issues.dlang.org/show_bug.cgi?id=17592
>>
>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>>
>> Alex
>
> No responses!?

dtors not being virtual is the root cause of this issue (note the ctors aren't either but that's a bit different due to how super() works). This cant be fixed easily. Maybe the most simple workaround would be an @assumenogc attribute.

On 07/09/2017 09:51 PM, 12345swordy wrote:
> 
> No responses!?

FWIW, traffic on this NG tends to slow down on the weekends. I've long wondered if most of the activity here is when people need a break during their workday ;)

On Monday, 10 July 2017 at 03:41:15 UTC, Lamex wrote:
> On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:
>> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
>>> I have submitted a bug report regarding this:
>>> https://issues.dlang.org/show_bug.cgi?id=17592
>>>
>>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>>>
>>> Alex
>>
>> No responses!?
>
> dtors not being virtual is the root cause of this issue (note the ctors aren't either but that's a bit different due to how super() works). This cant be fixed easily. Maybe the most simple workaround would be an @assumenogc attribute.

I redundant to create a poor man's destructor void function named "clear()" for every class it allocated, every workaround I come across here around involves ugly hacks. Even Automem has it's on way of calling the destructor in a @nogc context.

Regardless, this is very frustrating for me to do manual memory management with class in a @nogc context without resorting to hacks and third-party libraries. I hope that the current main devs would tackle this in the upcoming releases.

On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:
> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
>> I have submitted a bug report regarding this:
>> https://issues.dlang.org/show_bug.cgi?id=17592
>>
>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>>
>> Alex
>
> No responses!?

See long standing `rt_finalize` issue [1], it's unfortunately a non-trivial problem.

[1] https://issues.dlang.org/show_bug.cgi?id=15246

On Monday, 10 July 2017 at 17:27:54 UTC, Moritz Maxeiner wrote:
> On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:
>> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
>>> I have submitted a bug report regarding this:
>>> https://issues.dlang.org/show_bug.cgi?id=17592
>>>
>>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>>>
>>> Alex
>>
>> No responses!?
>
> See long standing `rt_finalize` issue [1], it's unfortunately a non-trivial problem.
>
> [1] https://issues.dlang.org/show_bug.cgi?id=15246

What's the progress regarding fixing it?

On Monday, 10 July 2017 at 20:10:58 UTC, 12345swordy wrote:
> On Monday, 10 July 2017 at 17:27:54 UTC, Moritz Maxeiner wrote:
>> On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:
>>> On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:
>>>> I have submitted a bug report regarding this:
>>>> https://issues.dlang.org/show_bug.cgi?id=17592
>>>>
>>>> This is IMO severely limit the usage of emplace and destroy when it comes to manual memory management. The solutions that I find here involves very hackish solutions which is not idea for me.
>>>>
>>>> Alex
>>>
>>> No responses!?
>>
>> See long standing `rt_finalize` issue [1], it's unfortunately a non-trivial problem.
>>
>> [1] https://issues.dlang.org/show_bug.cgi?id=15246
>
> What's the progress regarding fixing it?

AFAIK people disagreeing on how to proceed, because there's no one correct answer, it's a matter of policy.
And then there's the fact that hardly anyone uses @nogc currently, anyway, because this is not the only issue with it, see the (somewhat) controversial @nogc Exception PRs by Walter for one other problem [1][2] - idiomatic D code is essentially impossible atm with @nogc, unless you use hacks like preallocated exceptions. Another issue is how std.experimental.allocator.IAllocator and @nogc can fit together (because the interface can't be declared as attributed AFAIK).
I understand your frustration, but right now the best option imho (read as: least time expensive) remains not using @nogc (ouch, I know) and if you really fear hidden GC allocations, use the -vgc to have the compiler output all the placed where GC allocation may occur (grep through the result automatically, ensuring there are none reported); doesn't work for binary dependencies, unfortunately.

[1] https://github.com/dlang/druntime/pull/1804
[2] https://github.com/dlang/dmd/pull/6681