Objects casting and custom destructor

[YaDev]

Description

An error occurs when defining a custom destructor (=destroy) for a Child object type after calling a parent procedure using type conversion from Child to Parent. Specifically, the compiler throws an error:

Cannot bind another '=destroy' to: Child; previous declaration was constructed here implicitly: refer to procCall Parent(c).parentCall

Here is the code that produces the error:

type
  Parent = object of RootObj
  Child = object of Parent

proc parentCall(p: Parent) =
  echo $p.type

## This one works
# proc `=destroy`(c: Child) =
#   echo "Child destructor" 

proc childCallParent(c: Child) =
  procCall Parent(c).parentCall

### Error : Cannot bind another '=destroy' to: Child; previous declaration was constructed here implicitly: refer to procCall Parent(c).parentCall ###
proc `=destroy`(c: Child) =
  echo "Child destructor"

let c: Child = Child()
c.childCallParent

Nim Version

2.1.0
2.0.8
1.6.20

Current Output

Cannot bind another '=destroy' to: Child; previous declaration was constructed here implicitly

Expected Output

No errors

Possible Solution

If the =destroy procedure is defined before the childCallParent procedure (and the type conversion), the program compiles and runs correctly. Uncommenting the first =destroy proc and removing the second one resolves the issue.

However, this workaround is not ideal because it imposes restrictions on the order of procedure definitions.

Additional Information

No response

[Araq]

That's just how it works, no bug here.

[YaDev]

The issue is not with the basic concept of how destructors work or type conversions, but rather with how the compiler handles the implicit creation of destructors when casting between related types. The fact that an implicit destructor interferes with an explicit destructor definition without a clear message suggests there might be room for improvement in how this is handled.

Even if this behavior is technically correct according to the current Nim specification, it can lead to confusion for developers, especially when dealing with complex inheritance structures. If this is intended behavior, clarifying it in the documentation could help prevent misunderstandings in the future. If it’s not intended, then addressing it could improve the developer experience.

I’m not claiming that it’s definitively a bug, but I believe it warrants further discussion to see if this behavior could be made more intuitive or better communicated.

[Araq]

There is no need to discuss it, in Nim v3 this restriction will be gone.