Does mojo guarantee that the __del__ destructor is always called when a value goes out of scope?

[rarebreed]

So as the title asks does mojo guarantee that the destructor is always called when a value goes out of scope? I was wondering about this from the programming manual

For what it’s worth, Mojo does internally have an equivalent of the Rust mem::forget function, which explicitly disables a destructor and has a corresponding internal feature for “blessing” an object, but they aren’t exposed for user consumption at this point.

I came across some interesting reading about rust and some issues in creating async structured concurrency. At least part of the problem (amongst others), is that rust does not guarantee calling its drop function to deallocate memory when an object goes out of scope. It is possible in certain circumstances (notably Rc) that std::mem::forget is called instead.

This non-guarantee of a destructor being called has had some profound impact on rust's type system and language design. The infamous rust leakpocalypse was discovered days before rust's 1.0 release, and there was some discussion about a Leak marker trait (similar to Send or Sync for example).

My understanding is that a lot of this could have been avoided if destructor calls were guaranteed to run rather than basically leaking memory (which is not considered Undefined Behavior). But I also wonder...is it even possible to guarantee?

For example, how would you handle FFI where the foreign language will be managing the memory? This would include syscalls to the OS, so it seems like the ability to purposefully leak memory is required. And if that is the case, then you run into the rust dilemma about a Leak marker trait (while a !Leak trait bound on a type would have enabled the compiler and users to know that "this data type can't be leaked", it would have been a painful end-user experience).

[rarebreed]

I guess scope is the wrong word here since mojo seems to call the destructor at its last usage rather than the end of a scope, unless there are still references to it. So perhaps the question should be read as will the destructor always be called at a variable's last use?

[lattner]

Sorry I didn't see this earlier. Mojo has more aggressive policy than Rust that I call "ASAP" destruction - it doesn't wait until end of scope. Check out this link for more details: https://docs.modular.com/mojo/programming-manual.html#behavior-of-destructors

[rarebreed]

Hi Chris :)

I saw that documentation after I had written the initial post, but I was still wondering if it's possible to circumvent the destructor from being called and if yes, what the ramifications would be.

For example, how will mojo handle FFI and handing off some data with heap allocated memory to some other runtime/program? Without this, mojo itself may deallocate the memory. I saw that mojo has an internal version of rust's std::mem::forget function, so I was thinking perhaps mojo will expose this publicly. However, that leads to a host of other questions:

• How will mojo handle rust's version of unsafe?
• Would mojo's version of std::mem::forget be considered safe (rust considers leaking memory to be safe)?
• If memory deallocation is no longer guaranteed, then mojo may eventually run into the issues rust had with their leakpocalypse without some kind of marker trait like Leak

[lattner]

We don't have answers to these questions, but I can give you MHO. These aren't "team" or "modular" opinions, just based on my experience of where I guess things will go:

1. no we will not have an unsafe. I don't think this has played out well for Rust and Swift has a different approach that has worked out much better IMO.
2. n/a, and it isn't clear to me that we should expose this anyway.
3. Perhaps, we'll have to see.

Rust made a bunch of very specific an intertwined decisions that Mojo is not making, so while I can see that you're concerned about this, I wouldn't worry much about it.

Python doesn't even have access control (public/private) so we have a lot more fundamental things to work through than mem::forget.

[rarebreed]

Thanks for the reply :)

I don't know much about programming language theory, so I was wondering how things might play out.

I'm definitely very curious how mojo will turn out. I've gone from being a rust champion at work, to having a lot of hopeful optimism that mojo is picking the winning strategy (of being a python++) going forward.

[lattner]

Of course, you can also just call malloc and free from Mojo and ignore "smart pointers" etc. If you do that, safety is in your own hands :)