// `Color` doesn't implement `Copy` trait here.
struct Color(u8, u8, u8);

fn main() {
    let color = Color(32, 32, 32);
    let Color(r, g, b) = color;
    // rustc doesn't complain about this:
    println!("color: ({}, {}, {})", color.0, color.1, color.2);
}

What happened in the second let statement? Does the variables r, g, and b move the ownership of color in this example? Or it will move or copy the value of the members of color depending on the members' own rules? In other words, does Rust regard the Color(r, g, b) as a single object applying the rules of moving and copying semantics of Color or only applying the rules members owned? — in my test, I noticed that I still could use color after destructuring without any compilation failure, whereas Color doesn't implement Copy trait, which is weird.

I question this here because I noticed that color: Color(32, 32, 32) is regarded as a single value here, but Color(r, g, b) seems to be regarded as three separated variables, and I couldn't use (r, g, b) to destruct the c as an error occurred in compilation: mismatched types, which makes me confused — if Rust regards r, g, and b as three separated and independent variables, then why I must specify the structure which is similar to a construction explicitly rather than using a tuple to destruct the tuple structures directly? The former one makes me unsure that whether the = operation of Color(r, g, b) is applied by the ownership rules of the Color itself or its members — in the example, Color cannot Copy but u8 could.

2 posts - 2 participants

Read full topic