Mostly. In the former case, the variables you don't bind will drop immediately. In the latter case, they will stick around until the end of their lexical scope.
The only difference is that in the first one the rest of the fields will be dropped before the rest of the code is run, whereas in the second one the rest of the fields will be dropped at the end of the scope. So for example if your StructTest contained a non-empty vector, with the first method its memory would be freed before you printed a whereas with the second method its memory would be freed after you printed a.
yes,the former case, the instance of struct will be drop immediately,but not the "a",the "println!("{}",a)" still can work.so ,i think maybe for "a" is let a = st.a;
yes,i know that,sorry maybe i unclear description the question,i mean the var "a",because of the println still can work,so,i guess maybe for the "a",the code is:let a = st.a; ?
This is part of Rust's pattern matching capabilities, and applicable to more than just structs. See this section in the book.
But the comments about A dropping(never creating maybe??) a TestStruct and B creating both a TestStruct and then a from it are spot on. Does A actually initialize and drop a full instance of TestStruct? Or is the default passed directly to a?
Semantically, it has to initialize and drop the full struct, but this might be elided by the optimizer if neither the construction nor the drop impl have any observable effects.
Ohh, neat. Good way to check on that. But does Droppy having drop effects make it so no level of optimization would elide away the creation/drop? Feels like I'm asking about Schrodinger's cat now...
Not that I have a use case for it, but is there a more direct way to access just a single field's default value?
At this point we might be picking on definitions. Certainly the semantics of the language don't permit the compiler to delete or move the println!() statement. But Droppy is zero-sized so probably no actual memory allocation is taking place anyway.
I wouldn't worry about the performance impact of this in any case.
Not really, today. Maybe someday. You could follow some of the ideas in that thread, in many cases -- make some associated consts for your struct, which are individually available, and also use them to implement Default manually. But there's no built-in support for it currently.
However, if you just #[derive(Default)]'d, you could just use FieldType::default() since that's what the derived implementation does.
If you're worried about performance and not ergonomics, though...
...I agree with this. Default::default() is usually cheap and this use case is probably an easy target for the optimizer to boot.