Sort by

The reason for how #[derive(Debug)] works is consistency and clarity.

There are very few traits that are automatically implemented but it would not make sense for Debug. Keeping them minimal is important for language simplicity.

Imagine you make a struct where all of its fields are Debug. You print it out somewhere else. Then change a field to be non-Debug. Which means you can't print it anymore. It is clearer and easier to know if a certain struct is Debug or not this way. It also means that the way it works is exactly like other traits and also deriving other traits. Consistency makes learning it and using it easier, less special cases.

Best video by far in terms of snippets, closeups, code and font size. Also, I know rust reasonably well (I'm a c programmer predominantly). But your take always gives a slightly new spin and is different from anything else re this subject. You deserve more subs. That will come.... Wayne's world.... looking forward to enums... They are awesome!

17:30 -ish: I think a big reason APIs generally prefer to do their mutations through mutable references rather than through passing ownership is probably related to performance.

Say, for example, you have some struct `HugeStruct`, that has like a bajillion different fields, none of which are Copy. Say you have a method `change_single_part` that just goes into one of those fields and tweaks it a little bit. If you take ownership with a regular old `self` and spit out a new `HugeStruct` with the different value, you're doing a bunch of moves. The problem is that when Rust sees you move a value, what's really happening in the code the compiler generates for LLVM (as far as I can tell by a quick Google; I'm no expert) is that it will `llvm.memcpy` the old value into the new place. This means Rust's "moves" are secretly really done by 1. copying, 2. making using the original illegal afterward. Often this doesn't come up, because the compiler is often smart enough to elide `memcpy` calls if it sees that it can. But sometimes this elision fails.

If you use `&mut self` instead, then you don't have to rely on the compiler doing these optimizations for you---you can just mutate whatever's inside the struct in-place.

EDIT: another, probably bigger, reason is that if the function's caller doesn't have ownership, but they have a mutable reference, they can call `&mut self` methods, but they can't call just straight up `self` methods.

If I don't own a vector, but I do have a mutable reference to it, I'd still like to be able to call methods on that vector that mutate it, like `sort()`---whoever gave me the mutable reference was fine with me changing the vector. But if `sort()` took `self`, this basically means "if you call me, you'd better be the final arbiter of when this thing dies", which is more demanding than "you'd better have permission to mutate it" like `&mut self` would imply.

You can turn on argument name hints in loads of IDEs including vims and such. It will essentially look like how you imagined Something::new(this: u32, that: f64) and usually also hints at types like this let x: f64 = 0.0; the ":f64" would be put in by the editor.