www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Should struct destructors be required to be nogc?

reply bachmeier <no spam.net> writes:
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.
Sep 13 2023
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 13 2023
parent reply Commander Zot <no no.no> writes:
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.
Sep 14 2023
parent reply deadalnix <deadalnix gmail.com> writes:
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.



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.
Sep 15 2023
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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.



 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
Sep 15 2023
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 14 September 2023 at 01:39:25 UTC, bachmeier 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.


Since 2.102 you should get a stack trace now. Did that not happen 
for you?

-Steve
Sep 14 2023
parent bachmeier <no spam.net> writes:
On Thursday, 14 September 2023 at 08:31:05 UTC, Steven 
Schveighoffer wrote:

 Since 2.102 you should get a stack trace now. Did that not 
 happen for you?

 -Steve


I'm using the LDC package for Ubuntu 22.04, which is LDC 1.28, 
based on 2.098. That might have helped. I think in this case, 
though, the compiler should have caught the problem and refused 
to create the binary.
Sep 14 2023