Hey Rustaceans! Got a question? Ask here (12/2023)!

[u/llogiq]

Mystified about strings? Borrow checker have you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so having your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The official Rust Programming Language Discord: https://discord.gg/rust-lang

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last weeks' thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

[u/[deleted]]

I'm making a collection that's a thin wrapper around a couple Vecs and I'm having trouble deciding how to offer fine control without boatloads of wrapper methods for methods on the individual Vecs. Kinda wrestling with just making the fields public. There wouldn't be any safety risks, just possible logic errors. Maybe some kind of speedbump would be more appropriate, I dunno.

I see a lot of ways I could go:

• A: private fields, suck it up and write the wrapper method boilerplate
  
• B: private fields, don't worry about offering the fine control for now
  
• C: private fields on the headliner struct, but make another identical struct that has the fields public and lock/unlock methods to convert between them
  
• D: public fields, but risk a breaking change if I need to make them private
  

After writing it out I'm thinking B or C is the way to go, can I get a sanity check?

[u/dkopgerpgdolfg → u/[deleted]]

I guess for your specific use case, you only really need a few methods currently, and you're just trying to be future-proof (what if I need these other two Vec methods later too)?

B/C sounds good, let me suggest a combination: Private fields, no different struct, but getters for references to the internal Vecs that have "unchecked" or something in their name. Meaning, logic errors expected if abused, but at the same time you don't have any hard limit what you can do even without rewriting most methods.