Confusion with owned integers
I tried the replacing
String
from the example in the docs and got an error when running build.
Docs example
My modified example
Error
---
If I replace Int
with String
it builds ok.
22 Replies
Btw the error is similar to what I get if I call
You are passing the ownership from one scope to another and thus this variable gets "consubed" by a function
I think it's similar to Rust, but I'm not perfect not in Rust nor in Mojo, these are just my thoughts
Congrats @, you just advanced to level 2!
Yeah, this is correct
You can't use the original one declared because that was consumed by your function call, albeit it did pass ownership back when you assigned it to y in your Int example
Even though you do have that object under y, x is now invalid
I think the compiler's behavior on this isn't fully fleshed out, or blocked on traits, and that's why it worked with
String
when it ideally shouldn't@b4rdarian I tried the above code but changed
let x
to var x
:
This works and prints x=10 and y=15, but there is a compiler warning: 'x' was declared as a 'var' but never mutated, consider switching to a 'let'
So making x mutable unblocks the code and clearly copies x as expected, but the compiler tells us to switch to let
, which gives a compiler error. The docs note: "Currently, Mojo always makes a copy when a function returns a value." So I'm not quite sure where this leaves us.I think the compiler's behavior on this isn't fully fleshed out, or blocked on traits, and that's why it worked with String
when it ideally shouldn't
The example with the String was taken from the docs. Either the docs are wrong or I am missing something about how owned
should behave. Further down in the example it talks about how using ^
actually gives complete ownership, making the passed variable out of scope.I think that without ^, if the argument is owned, it should just make a copy (which seems pretty logical to me). Maybe the behavior is changing? I wouldn't be surprised if it changed more in the future, they are working on it indeed.
I suspect it relates to how
Int
s are actually stored under the hood with comparison to String
objects. I played a bit with another example from the docs (https://docs.modular.com/mojo/programming-manual.html#transfer-arguments-owned-and) yesterday,Modular Docs - Mojo🔥 programming manual
A tour of major Mojo language features with code examples.
Added a
__copyinit__
to UniquePointer
to allow copying.
From the example
Last call will fail as expected if uncommented.
These will fail compilation if the the commented lines are uncommented
Congrats @b4rdarian, you just advanced to level 1!
I think the docs need updating / clarification. I believe it relates to stack vs heap. So copying only works for objects stored in the heap.
I'm encountering the same problem.
I'm using modular playground.
The version of mojo kernel should be v0.4.0 at the time.
According to Argument mutability and ownership I modified the function from the example in the docs.
My modified example: Situation 1: a and b are declared as var The result:
It works.
Situation 2 a and b are declared as let The result: It looks like Mojo didn't make copies of a and b separately.
According to Argument mutability and ownership I modified the function from the example in the docs.
My modified example: Situation 1: a and b are declared as var The result:
It works.
Situation 2 a and b are declared as let The result: It looks like Mojo didn't make copies of a and b separately.
Modular Docs - Mojo language basics
A short introduction to the Mojo language basics.
So, did you mean it is not a bug?
I can't really say. It might be, all I am saying is that it doesn't work as it's described in the docs for primitive types.
Btw I am also basing my understanding on rust documentation on ownership https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html#ownership-and-functions
In that integers are copied rather than owned.
You might be right and it's a bug. I am on an M2 MacBook.
VSCode's mojo extension is not picking up on the error. Only when trying to compile.
@b4rdarian great research. I think this must be on the right track. This is probably worth filing an issue on the repo
Good call. Will do.
Apparently I am not the first to notice. There is already an issue open https://github.com/modularml/mojo/issues/747. I can see @Weichen-威辰 has added his experience to it.
GitHub
Issues · modularml/mojo
The Mojo Programming Language. Contribute to modularml/mojo development by creating an account on GitHub.
I will do the same.
Thanks for the link.
It helps me to get a better understanding of ownership.
Congrats @Weichen-威辰, you just advanced to level 1!