__moveinit__ and __del__
When the
__del__
method is not implemented, the __moveinit__
method is less likely to be invoked. Why is this the case? Consider the following example code:
On execution, the output is:
However, when we include the __del__
method as follows:
The output changes to:
The presence or absence of the __del__
method impacts the sequence of method calls __copyinit__
and __moveinit__
, potentially affecting the performance. Why does this occur?7 Replies
Because move init is always favored over copy init
I know moveinit is preferred but why does copyinit run when del is unimplemented?
From the programming manual:
I think it's because the compiler is smart enough to realize that copying would be more efficient with that type, but having custom
__del__
behaviour might disallow that? Just speculation but that's my guess+1, Mojo assumes/expects that you're implementing well behaved types
where "copy + del" is equivalent to "move"
This is true for "almost everything", and knowing this allows the compiler to perform optimizations that (e.g.) C++ and Rust can't do. The flip side of this is that if you implement a type where these properties aren't true for some reason that you'll have a bad day 🙂
The solution to that is to just play by the rules: you can implement your own copy and move methods (or come up with other exciting verbs 🙂 if you need to, and the compiler won't touch them
If you're familiar with C++ and care about performance you might see code litered with std::move operations etc, even for basic types like std::string and std::vector. Mojo allows you to relax a bit because it has your back and will generally "do the right thing" without you micromanaging it.
That said, if you're a control freak, then have at it with ^ etc.
Congrats @Chris Lattner, you just advanced to level 5!
Does that make sense to you?
I love witnessing the creation of this language. I love seeing so many twists and turns. It is beautiful to see how experience (yours haha) allows one to participate in both the basic and the complex at the same time. Holding the necessary focus to achieve the goal of having a language with the most beautiful high-level syntax, and not only "the possibility of interacting with low level" but making it competent in comparison with C++ or Rust, which already has its good. deserved prestige.
Thank you @Chris Lattner, @Jack Clayton and the entire Team for doing this. 🙂