Representation for assignee expressions in assignment expressions

[xFrednet]

The reference defines assignment expressions to have the grammar:

AssignmentExpression:
Expression = Expression

which makes sense. However, it becomes slightly more complicated when the assignee expression is an array, a tuple or a struct with fields, as these can contain wildcard/underscore and rest expressions (as shown below and on the Playground).

a += 1;
[a, b] = [1, 2];
S {
    array: [_, a, ..],
    slice: (b, ..),
} = S::default();

The wildcard/underscore expression is AFAIK only used to allow such assignments. The rest expression, is not listed and on a lexicographical level probably a range expression without limits.

While this works, it feels weird to me. When I think about assignments, I see the left-hand side as a pattern. Adding a wildcard/underscore expression just for assignments also doesn't feel quite right.

Rustc desugars such expressions into a let-statement with a pattern and variables that are then reassigned. This can be seen with Show HIR on the Playground.

---

The question of this issue is, how should the assignee be represented in Marker?

1. With expressions, like the grammar would indicate
2. With patterns and some way of including place expressions in patterns

[xFrednet]

I've played around with both options and currently prefer the second one. The pattern nodes are already used for let-statements, using them would make the representation of the assign expression be similar. Helper functions for let-statements can then potentially be reused by assign expressions. I also believe that it'll be simpler to document the API if patterns are always used as assignees.

Representing it as a pattern is also closer to my mental model, but that is not really a good argument.

I've tried implementing the first version in the branch 052-expr-as-assign-target but stopped half way, as it didn't feel quite right. I've implemented the second option in 052-assign-exprs which seems to work well. I'll create a PR for the second solution to see how it feels over time.

This has to be discussed before v1.0.0, even if we agree that the current version is working well. Any feedback is as always welcome :)