Mirror of forum.nim-lang.org

10395 :: Nim 2 and need for try-finally?

• radekm (orginal) [2023-08-11T12:15:41+02:00] view original

  Hi,

  since Nim 2 brought ARC/ORC it is tempting to stop using try-finally for disposing resources. Because now =destroy will be called automatically when reference count drops to 0.

  But some examples in stdlib documentation eg. std/httpclient still use try-finally. When I looked into the sources of stdlib I was unable to find =destroy for Socket and for SocketHandle. So does it mean that try-finally is still necessary?

  Thanks

---

• blackmius (orginal) [2023-08-11T12:21:50+02:00] view original

  yes try/finally still needed for types lacking =destroy. If you using low level primitives like handles which rarely used in c bindings you still need to free resources yourself. So having SocketHandle is just a distinct cint and you need call close on created socket to free it usage in OS

---

• Araq (orginal) [2023-08-11T12:23:16+02:00] view original

  Unfortunately large parts of the standard library don't embrace destructors yet. Sorry!

---

• termer (orginal) [2023-08-12T02:48:09+02:00] view original

  It's worth documenting part of the stdlib that have their resources freed with a =destroy hook since it's currently the exception, not the rule. I wouldn't mind contributing a little bit to this, but I suspect it might conflict with existing try/finally uses if there are new =destroy hooks added.

  @Araq Is there expected to be problems for most =destroy hooks if they're called multiple times? I'm assuming there are a lot of resources that if a =destroy hook was added to them, that existing code with try/finally might end up trying to free resources twice.

---

• ElegantBeef (orginal) [2023-08-12T03:18:49+02:00] view original

  Any types like that should have =copy disabled, and places that take ownership annotated with sink. That's a relatively large and breaking change though.

---