`..user1` *muss* als letztes kommen und füllt dann alle bisher nicht gesetzten Felder.
Außerdem ist das etwas tricky:
Wenn die Daten, die von `user1` zu `user2` übertragen werden, gemoved werden (sprich: keine primitiven Datentypen sind), dann ist `user1` danach ungültig.
Hätten wir jetzt auch noch einen neuen `username` gesetzt (auch ein String) und nur `active` und `sign_in_count` übertragen, wäre `user1` noch gültig.
Das Buch meint, man könnte für diesen Datentypen jetzt noch Traits implementieren, aber davon habe ich noch keine Ahnung.
Nur dann macht diese Art von Struct irgendwie Sinn.
== Ownership der Felder
Im ersten Beispiel wird `String` satt `&str` genutzt.
Wir wollen am besten im Struct keine Referenzen, oder es müssen "named lifetime parameter" sein, etwas das wir erst später lernen.
Der Compiler wird sonst streiken.
== Das erste Mal Traits
Im Buch folgt ein Beispielprogramm für ein Struct, das ein Rechteck abbildet.
Wir wollten das ganze printen (mit `{}` als Platzhalter), allerdings implementiert Das Rechteck nicht `std::fmt::Display`.
Das scheint eine Art `toString()` für Rust zu sein.
Es gibt aber noch eine andere Möglichkeit und das haben wir schonmal für Tupel genutzt:
`{:?}` als Platzhalter (bzw. `{:#?}` für pretty print).
Dafür brauchen wir aber das Trait `Debug`.
Zum Glück scheint das aber einfach zu implementieren sein, es muss nur implementiert werden.
Der Compiler schlägt uns zwei Varianten vor:
1. `#[derive(Debug)]` über der Definition des Structs
2. `impl Debug for Rectangle` manuell
Jetzt können wir Variablen dieses Typs printen und es zeigt uns Datentyp und Felder an.
Alternativ kann man auch das Makro `dbg!(...)` nutzen.
Das wird dann auf `stderr` geprintet.
Man kann sogar ein Statement da rein packen (also zum Beispiel `30 * x`) und bekommt das Statement mit dem Ergebnis geprintet, wobei das Ergebnis (als Wert, nicht Referenz) auch zurückgegeben wird.
== Funktionen in Structs
Unser Struct soll jetzt auch eine Funktion auf sich selbst aufrufen können.