this post was submitted on 25 Mar 2024
11 points (100.0% liked)

Learning Rust and Lemmy

231 readers
1 users here now

Welcome

A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.

Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.


Running Projects


Policies and Purposes

  1. This is a place to learn and work together.
  2. Questions and curiosity is welcome and encouraged.
  3. This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
  4. This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.

See also:

Rules

  1. Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
  2. Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
  3. Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
  4. See the Lemmy Code of Conduct
  5. Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities


Thumbnail and banner generated by ChatGPT.

founded 1 year ago
MODERATORS
 

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?

top 4 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 11 months ago (1 children)

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 by take_ownership which would be straightforwardly owned by s2 throughout main. Meanwhile s within take_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 to take_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 the take_ownership call, then that'd require a borrow, which would require modifying both main and take_ownership, so who knows?

[–] InternetCitizen2 3 points 11 months ago (1 children)

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.

[–] [email protected] 2 points 11 months ago

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);
}
[–] [email protected] 1 points 11 months ago

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 in main() 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 touching main() 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.