On Wednesday, September 13, 2023 7:39:25 PM MDT bachmeier via Digitalmars-d wrote:
> I recently had an invalid memory operation error, and given how vague that message is, I had no idea where to look for the problem. The problem was string concatenation in a struct destructor. My feeling is that destructors should always be @nogc, because if it's not, you've done something wrong and your program might unexpectedly crash.
>
> After solving the problem, I came upon [this page](https://wiki.dlang.org/InvalidMemoryOperationError). If the error message had at least included a link to that page, it would have saved me a lot of time.

Well, if the class or struct is on the stack, being @nogc should be unnecessary (the same if you're using an allocator other than the GC allocator), because it won't be run when the GC is running a collection. So, arguably, requiring @nogc would be too restrictive for some use cases. However, it's also true that they could just as easily be on the heap and run into a similar issue (particularly with classes, since they almost always live on the GC heap). So, an @nogc requirement would likely make sense for most use cases, but I don't know how reasonable it is to absolutely require it.

- Jonathan M Davis

On Thursday, 14 September 2023 at 03:03:38 UTC, Jonathan M Davis wrote:
> On Wednesday, September 13, 2023 7:39:25 PM MDT bachmeier via Digitalmars-d wrote:
>> [...]
>
> Well, if the class or struct is on the stack, being @nogc should be unnecessary (the same if you're using an allocator other than the GC allocator), because it won't be run when the GC is running a collection. So, arguably, requiring @nogc would be too restrictive for some use cases. However, it's also true that they could just as easily be on the heap and run into a similar issue (particularly with classes, since they almost always live on the GC heap). So, an @nogc requirement would likely make sense for most use cases, but I don't know how reasonable it is to absolutely require it.
>
> - Jonathan M Davis

i'd prefer: don't call destructors from the GC at all, it was never guaranteed anyway as far as i know. introduce finalizers, which are _only_ called by the GC and are @nogc.

On Thursday, 14 September 2023 at 09:29:21 UTC, Commander Zot wrote:
> i'd prefer: don't call destructors from the GC at all, it was never guaranteed anyway as far as i know. introduce finalizers, which are _only_ called by the GC and are @nogc.

I don't see why that should be a problem at all. Java, C# and friend all support allocation during finalization and even object resurrection.

At some point, we got to stop chasing the new trendy feature, and make sure the one we have work properly up to the standard a modern dev can expect.

On Friday, September 15, 2023 5:32:00 PM MDT deadalnix via Digitalmars-d wrote:
> On Thursday, 14 September 2023 at 09:29:21 UTC, Commander Zot
>
> wrote:
> > i'd prefer: don't call destructors from the GC at all, it was never guaranteed anyway as far as i know. introduce finalizers, which are _only_ called by the GC and are @nogc.
>
> I don't see why that should be a problem at all. Java, C# and friend all support allocation during finalization and even object resurrection.
>
> At some point, we got to stop chasing the new trendy feature, and make sure the one we have work properly up to the standard a modern dev can expect.

I don't know enough about what D's GC is doing to know why it can't handle this (or if I knew, I forgot), but certainly, I would agree that ideally, the GC would just be able to handle having stuff allocated while a destructor is running. And unless there's something fundamental preventing it in D's case, it would definitely be a better solution than disallowing allocating in destructors, much as needing to allocate in destructorss should be pretty rare.

- Jonathan M Davis