this post was submitted on 25 Sep 2024
37 points (100.0% liked)

Rust Programming

8127 readers
1 users here now

founded 5 years ago
MODERATORS
 

Rust ownership is a fundamental part of the language.

I’ve summarized the basic concepts here as a learning exercise for myself.

I’m sharing this to gather feedback, corrections, and suggestions.

Feel free to offer improvements wherever needed!

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 1 month ago (2 children)

Avoid clone() options ^_^

I don't really like that as general advice. A lot of the time a clone is perfectly valid and fine thing to do. More often then not I will read for a clone rather then an Rc or Arc. Its fine, you dont need to be afraid of it. And it misses the more important advice - avoid allocating in tight loops.

There are lots of ways you can allocate data. Clone being only one and not even all clones will allocate data. So it is a poor thing to get hung up on. If you have an Rc or Arc then clones are cheap. Stack only data is also cheap to clone (and is often copy). Some structs internally use Arc or Rc or are just simple wrappers around copyable types. And it misses other forms of allocations, creating Strings or Vecs, boxing data etc. All of these things including cloning are fine most of the time. But should be avoided in tight loops and performance sensitive parts. And when learning it quite often does not matter that much to avoid them at all.

I have seen quite a few people make things way harder for themselves by trying to avoid clone at all costs in all situations and IMO articles like this add to that as they never explain the main nuances of allocations and when you want to avoid them or when they are actually fine to use.

[–] [email protected] 1 points 1 month ago* (last edited 1 month ago)

yeah, I agree that there are definitely valid uses for clone(). I included it at the top of my table with a bit of humor, hence the smile. Thanks for pointing it out! ^_^

load more comments (1 replies)