fixup up struct init

_languages/rust-struct-initializer-mistake.md

@@ -76,11 +76,12 @@ Languages from the 70ies managed to get this right, Rust somehow regressed on th
 
 ### A Solution
 
-What Rust could have done instead:
+What Rust should have done instead:
 
 - Function calls and struct/enum initializers use `()`, not a mix of `{}` and `()`.
 - Have *one* ruleset that all those invocation follow.
-- Use `=` for passing actual values as named arguments, such that everything "just works" if default parameters are added in the future.
+- Use `=` for passing actual values as named arguments, such that everything "just works" if default parameters were added in the future.
+  (See the [Appendix](#appendix-a-detailed-look-at-the-role-of) for an evaluation of available options.)
 - Shorthand notation or positional arguments? Pick one.
 
 Adapting the example code from above, the code would look like this:
@@ -103,7 +104,9 @@ fn main() {
 }
 ```
 
-#### How to Distinguish between a variable assigment and a named parameter use inside a function invocation?
+### Appendix: A Detailed Look at the Role of `=`
+
+#### How to distinguish between a variable assigment and a named parameter use inside a function invocation?
 
 Example:
 
@@ -115,13 +118,11 @@ 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?
+  - Intuitivity: How can the syntax be distributed to those two use-cases such that the choice makes intuitively sense from a user point-of-view?
 2. Reducing the harm from mix-ups:
-  - Can code that looks correct be interpreted unexpectedly? I. e.
-
-In general, there are multiple options:
+  - Can code change meaning unexpectedly, e. g. when function parameters are renamed?
 
-##### Try to use the same syntax for both variable assigments and named parameters
+##### Option 1: 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.
 
@@ -134,9 +135,9 @@ The danger with this approach is that changing the name of a named parameter can
 
 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
+##### Option 2: 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.
+In this example, the workaround 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
@@ -147,8 +148,7 @@ In this example, the orkaround syntax for named parameters is a `.` prefixed to
     // 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
+##### Option 3: Let named parameters use the "good" syntax and give variable assignments some "workaround" syntax
 
 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]