cross-posted from: https://lemmy.world/post/13508677
Hello All:
I am working on rust problems here. In the second question I solved it by simply adding the return statement for the function to modify. I am not sure what the lesson in ownership to walk away with in this problem. Any guidance?
I don’t think I’d seen that page … how are you find it (this question excluded)?
This is the question I found:
// Don't modify code in main! fn main() { let s1 = String::from("Hello world"); let s2 = take_ownership(s1); println!("{}", s2); } // Only modify the code below! fn take_ownership(s: String) { println!("{}", s); }
As far as I see, there’s no ownership issue that I can see, as
s2
is simply whatever is returned bytake_ownership
which would be straightforwardly owned bys2
throughoutmain
. Meanwhiles
withintake_ownership
is obviously owned within that scope.I’m thinking you’re right and that it’s a poorly built exercise. We could speculate on what they were trying to do … such as trying to print
s1
after it has been moved totake_ownership
… but in the end it’s a relatively simply bit of code and we’d probably be better off moving on … unless I’m missing something of course.If the idea were to print
s1
after thetake_ownership
call, then that’d require a borrow, which would require modifying bothmain
andtake_ownership
, so who knows?Yes that is the question in question. I just was not sure what principle of ownership was in play to answer it since just adding the returns fixed the question. Perhaps it was supposed to be for another problem set and it got posted with these by accident.
Yea, something seems off. Probably best to move on.
If you want a problem … here’s my quick modification to make it about ownership. You can modify both functions. By the sounds of it though you might be on top of this.
fn main() { let s1 = String::from("Hello world"); let _ = take_ownership(s1); println!("{}", s1); } fn take_ownership(s: String) { println!("{}", s); }
I agree with @maegul that this is probably just a poorly built exercise and/or overlooked by the creators on their “final” pass. Especially given that printing out the unit type
()
(as the code inmain()
effectively does) makes very little sense.However, I do see a way to “fix” the ownership “issues” that makes the rest of
main()
make sense, without touchingmain()
itself:fn take_ownership(s: String) -> String { println!("{}", s); s }
Basically what you stated you did to solve it, though I wanted to highlight that you might want/need to explicit the return type as well as actually returning the
s
parameter.