This is one of those features that “just works”, and users don’t even need to think about them, so the documentation is more for understanding the AST and confirming that this is something one can rely on.
This is one of those features that “just works”.
Right, but it feels risky to use an undocumented feature (maybe it’s a bug…).
My experience with filing a PR for the docs is that the core team takes it as a starting point. If you prefer, I could write up something simple, for instance, by borrowing your example (a[i][j], b[k]) = (2, 3). Maybe that would trigger someone to add details.
I discovered this just a few weeks ago myself when I had an occasion to update two refs at the same time like this. I wasn’t sure if it would do what I wanted so I checked the lowering and was happy to discover that it did.
Of course, we cannot do anything more interesting than constant-valued functions since the RHS is an immediately-evaluated value and not a function body.
Looking at the lisp, it looks like tuple destructuring is implemented exactly as a loop that generates the same code as a sequence of assignments for each thing on the LHS while iterating over the RHS. And I think it’s something you can count on as it’d be an error otherwise. Let’s document it!
in the dev docs, documenting the AST and the rules (which appear to be “anything that even remotely makes sense goes”, as @mbauman pointed out).
An issue first would help clarify what of this is intended, and what isn’t. Also, the two points above would not need to be addressed in the same PR — I think I would leave 2. for core devs.
Recently I’ve been writing a massive pile of tests for lowering which can partially serve the need of documenting the intent of lowering without having to refer to the code itself. Not everything is covered yet, but nested destructuring is: