Rust: What the fuck is a borrow checker and why is it yelling at me?

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Rust: What the fuck is a borrow checker and why is it yelling at me?

The March Hare: Oct 15, 2006; _{Je r�ve d'un}
Wayne's World 3; Buglord

I've always found it best to learn a language starting with the initial release and then redoing my projects feature-for-feature in each release after.

# ¿ Feb 4, 2023 01:59

Adbot: ADBOT LOVES YOU

# ¿ May 12, 2024 22:10

The March Hare: Oct 15, 2006; _{Je r�ve d'un}
Wayne's World 3; Buglord

Hi, lifelong Python guy here. Just getting into Rust and have some questions about how people handle things in more stringent type systems.

I'm making an HTTP request to an endpoint whose 200 response payload is stable - I do not anticipate its shape changing at all.

In Python, I might set up something like a struct mapping to all of the keys in the JSON response from this endpoint. That would be helpful for code completion and documentation for other devs on the project.

Using ureq in Rust they suggest doing just that - I can do something like:

code:

#[derive(Deserialize)]
struct DummyExpectedResponse {
    field1: String,
    field2: String,
    urMomsPhoneNumber: String,
    field3: String
}

let resp: DummyExpectedResponse = ureq::post...

This is gravy, except I may not need to use your mother's phone number in this program which leaves me with a linter warning about unused fields in the struct. Python linters, in my experience, would not complain about this.

My understanding is I can either prepend an underscore on fields that are unused, and then remove that underscore later when I use the fields, or I can slap an `#[allow(dead_code)]` at the top of the struct to tell the linter to chill out.

My brain tells me that this thing is useful as documentation and an interface. For that reason, I'd rather leave it unmolested - the underscores feel like they would be annoying to remove later and unlikely to clarify any question other than "which fields on this struct are in use in this program right now" - which doesn't seem like a very useful question to have an answer to.

For those reasons, I'm erring on just slapping `#[allow(dead_code)]` on it and calling a day. But I'm curious to hear how other people feel about this &or if there's some other way I could be solving this issue.

# ¿ Nov 3, 2023 21:32

The March Hare: Oct 15, 2006; _{Je r�ve d'un}
Wayne's World 3; Buglord

I appreciate knowing I can just leave them off entirely with serde_json (that is what I'm using, I think) but I think the real driving force behind my desire to leave them in the struct is as documentation of the shape of the response from the API.

If I remove them from the struct then I'll have to go inspect the response later if I want one of the other fields that I'm not using right now. Or, worse, I may think that everything in the struct _is the entirety_ of the shape of the response from the API, and not realize that I could also be accessing your mother's phone number, which would be a disaster for my love life.

What I'm less worried about is the "difficulty" of the refactor in terms of finger mechanics.

Moving them into their own little crate seems reasonable enough I guess, though it feels a little extra for just this little toy example. Feels like a solution I'd reach to if I were mapping a large part of a larger API or something though.

The March Hare fucked around with this message at 23:27 on Nov 3, 2023

# ¿ Nov 3, 2023 23:25

The March Hare: Oct 15, 2006; _{Je r�ve d'un}
Wayne's World 3; Buglord

Cool, thanks for all the replies everyone - all makes sense.

# ¿ Nov 4, 2023 14:16

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Rust: What the fuck is a borrow checker and why is it yelling at me?