update "Struct initializers in Rust"

Author: soc

_languages/rust-struct-initializer-mistake.md

@@ -92,8 +92,10 @@ struct User(
   active: bool,
   sign_in_count: u64 = 0) // default parameter value
 
+struct State(active: bool)
+
 fn user(username: String, email: String) -> User {
-  User(username, email, active = true) // named parameter
+  User(username, email, active = State(true)) // named parameter
 }
 
 fn main() {
@@ -107,15 +109,59 @@ Example:
 
     fun someFunction(a: Int64) = ...
     var a = 12;
-    let b = 23
-    someFunction(a = b) // what does this mean?
+    someFunction(a = 23) // what does this mean?
+
+Two points have to be considered here:
+
+1. Reducing chances of mix-ups:
+  - Frequency: Are variable assignments within function calls or function calls with named parameters projected to be used more often?
+  - Intuitivity: How can the syntax be distributed to those two use-cases such that the configuration makes sense from a user point-of-view?
+2. Reducing the harm from mix-ups:
+  - Can code that looks correct behave unexpectedly
+
+In general, there are multiple options:
+
+###### Try to use the same syntax for both variable assigments and named parameters
+
+This means that named parameters simply act like another scope in which identifiers are looked up.
+
+The danger with this approach is that changing the name of a named parameter can silently change the meaning of callsites if a variable with the previously used parameter name happens to be in scope.
+
+    // named parameter, but if someFunction's parameter name changes,
+    // without the callsite being updated, it silently becomes an
+    // assignment instead of a compilation failure:
+    someFunction(a = 23)
+
+It also means that variables with the same name as a parameter name cannot be assigned within a function call.
+
+###### Let variable assignments use the "good" syntax and give named parameters some workaround syntax
+
+In this example, the orkaround syntax for named parameters is a `.` prefixed to the parameter name.
+
+    // variable assigment inside a function argument list,
+    // only works if assignment returns the assigned value
+    // (which is generally a bad idea):
+    someFunction(a = 23)
+
+    // named parameter, and if someFunction's parameter name changes,
+    // without the callsite being updated, it becomes a compilation failure:
+    someFunction(.a = 23)
+
+
+
+###### Let named parameters use the "good" syntax and give variable assignments some workaround syntax
 
-Single rule: inside a functions argument list, the first level of `=` use is always a named parameter and never a
+Inside a functions argument list, the first level of `=` use is always a named parameter and never a
 variable assignment, even if some variable `a` would be in scope.[^2]
 
-If a variable assigment inside a function argument list is still needed, it could be expressed as: 
+    // named parameter, and if someFunction's parameter name changes,
+    // without the callsite being updated, it becomes a compilation failure:
+    someFunction(a = 23)
 
-    someFunction(a = { a = b; b }) // still possible
+    // variable assigment inside a function argument list,
+    // only works if assignment returns the assigned value
+    // (which is generally a bad idea):
+    someFunction(a = { a = 23 })
 
 
 [^1]: Except the tupled version of enums, for which initializers look like function calls again.