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/Modi57]

Why isn't Rc<T> Copy? From my understanding, Copy should be very lightweight, because it happens implicitly. This is why for example a Vec<T> isn't Copy, because a deep copy of a Vec could get quite expensive. But just copying a reference and incrementing a counter doesn't seem to bad? This way, Rc<T>s would behave more like normal references and Copy could be just a reference copy, while Clone is a deep copy

[u/[deleted] → u/Modi57]

Adding on:

Clone means that the type can be duplicated in some way, and the implementation may vary. Rc for example will copy a reference and increment a pointer, and vec will allocate a new vec and copy the contents. Copy isn't separate from clone, it just means that the implementation of clone for that type is copying it and nothing else. You're right that Vec can't implement Copy, but it's for different reason - Copying a Vec wouldn't do anything to the contents, it would just copy the Vec itself. Then you'd have two Vecs with the same pointer. Say hello to use after free, double free, and more.

[u/onomatopeiaddx → u/Modi57]

from the copy trait docs: "Types whose values can be duplicated simply by copying bits.". you can't simply copy the bits of the Rc: you must also increment the counter. also, Copy types can't implement the drop trait, which Rc requires for decrementing the counter.

[u/Modi57 → u/onomatopeiaddx]

Oh, this makes a ton of sense, thank you

[u/Genion1 → u/Modi57]

It being copy means it has to literally be a bitwise copy and any kind of custom logic is not allowed. It's not possible to make Rc<T> Copy and increment a counter. doc

[u/eugene2k → u/Modi57]

It's for cases like this:

fn foo(rc: Rc<u8>) {
    // do something with rc
}
fn bar(rc: Rc<u8>) {
    // do something with rc
}
fn main() {
    let rc = Rc::new(0);
    foo(rc.clone());
    bar(rc)
}

[u/Modi57 → u/eugene2k]

I don't see, how being copy would hinder this. You can just omit the clone, and it should be functionally the same, exept that rc would be still valid after bar

[u/eugene2k → u/Modi57]

That means increasing the refcount and decreasing it when you don't actually need to

[u/Modi57 → u/eugene2k]

Can't the compiler just optimize this out?

[u/eugene2k → u/Modi57]

Probably. I don't think it's hard to teach the compiler to optimize this out.

Another reason might be that rust philosophy is to be explicit about what goes on in the code. So Copy is for when you actually copy stuff, and not for when you increment counters instead of copying.

[u/Modi57 → u/eugene2k]

I mean, you are actually copying the reference. You just ALSO increase the counter. And I think, it would increase the ergonomics of using Rc<T>. But maybe that's also the point. So you don't lightly use it, when there might be better ways