Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Destructor not consistently called for different init forms #21244

Open
arnetheduck opened this issue Jan 9, 2023 · 4 comments
Open

Destructor not consistently called for different init forms #21244

arnetheduck opened this issue Jan 9, 2023 · 4 comments

Comments

@arnetheduck
Copy link
Contributor

Description

type X = object
  v: int

type Y = object
  x: X
  y: X

proc `=destroy`(x: var X) =
  echo "Destroying X"
  
  
proc f() =
  var y: Y = Y()
  echo y
  

proc g() =
  var y: Y
  echo y
  

echo "calling f"
f()

echo "calling g"
g()
calling f
(x: (v: 0), y: (v: 0))
Destroying X
Destroying X
calling g
(x: (v: 0), y: (v: 0))

In f, we initialize y to its defaults and destructors get called - in g we do the same but implicitly and the destructors are not called - I would expect the behavior to be the same in both cases so as to maintain semantic equivalence for both forms of default-init.

Nim Version

https://play.nim-lang.org/#ix=4kHG - latest on play

Current Output

No response

Expected Output

No response

Possible Solution

No response

Additional Information

No response

@arnetheduck arnetheduck changed the title Destructor not consistently called Destructor not consistently called for different init forms Jan 9, 2023
@Araq
Copy link
Member

Araq commented Apr 20, 2023

This is just cursor inference in action. y in g is optimized to a .cursor and so the destruction step is elided. Works your way when you compile it via --cursorInference:off.

@Araq
Copy link
Member

Araq commented Apr 20, 2023

We can disable the cursor optimizer for types with custom destructors but cursor inference for custom types is as useful as it is for builtin types and the "spec" allows it.

@arnetheduck
Copy link
Contributor Author

does the language allow eliding var y: Y = Y() if it can deduce that y is not used? what about let y = (ref Y)() or let y = new Y?

@Araq
Copy link
Member

Araq commented Apr 23, 2023

Yes, sure. Heap allocations can be optimized away as long as the observable behavior doesn't change. And side effects in destructors don't count as observable, just like in C++. (Not sure how good of an idea that one is but C++ got away with it for good.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants