title: *why* does list assignment flatten its left hand side?
body: <p>I understand that list assignment flattens its left hand side:</p>
  <pre class="lang-raku prettyprint-override"><code>my ($a, $b, $c);
  ($a, ($b, $c)) = (0, (1.0, 1.1), 2);
  say &quot;\$a: $a&quot;; # OUTPUT: «$a: 0»
  say &quot;\$b: $b&quot;; # OUTPUT: «$b: 1 1.1»    &lt;-- $b is *not* 1
  say &quot;\$c: $c&quot;; # OUTPUT: «$c: 2»        &lt;-- $c is *not* 1.1
  </code></pre>
  <p>I also understand that we can use <code>:($a, ($b, $c)) := (0, (1.0, 1.1))</code> to get the non-flattening behavior.</p>
  <p>What I don't understand is <em>why</em> the left hand side is flattened during list assignment.  And that's kind of two questions: First, how does this flattening behavior fit in with the rest of the language?  Second, does auto-flattening allow any behavior that would be impossible if the left hand side were non-flattening?</p>
  <p>On the first question, I know that Raku historically had a lot of auto-flattening behavior.  Before the <a href="https://perl6advent.wordpress.com/2015/12/14/day-15-2015-the-year-of-the-great-list-refactor/" rel="noreferrer">Great List Refactor</a>, an expression like <code>my @a = 1, (2, 3), 4</code> would auto-flatten its right hand side, resulting in the Array <code>[1, 2, 3, 4]</code>; similarly, <code>map</code> and many other iterating constructs would flatten their arguments.  Post-GLR, though, Raku basically never flattens a list without being told to.  In fact, I can't think of any other situation where Raku flattens without <code>flat</code>, <code>.flat</code>, <code>|</code>, or <code>*@</code> being involved somehow.  (<code>@_</code> creates an implicit <code>*@</code>).  Am I missing something, or is the LHS behavior in list assignment really inconsistent with post-GLR semantics?  Is this behavior a historical oddity, or does it still make sense?</p>
  <p>With respect to my second question, I <em>suspect</em> that the flattening behavior of list assignment may somehow help support for laziness.  For example, I know that we can use list assignment to consume certain values from a lazy list without producing/calculating them all – whereas using <code>:=</code> with a list will need to calculate all of the RHS values.  But I'm not sure if/how auto-flattening the LHS is required to support this behavior.</p>
  <p>I also wonder if the auto-flattening has something to do with the fact that <code>=</code> can be passed to meta operators – unlike <code>:=</code>, which generates a &quot;too fiddly&quot; error if used with a metaoperator.  But I don't know how/if auto-flattening makes <code>=</code> less &quot;fiddly&quot;.</p>
  <p>[edit: I've found IRC references to the &quot;(GLR-preserved) decision that list assignment is flattening&quot; as early as early as <a href="https://logs.liz.nl/perl6/2015-05-02.html#19:06" rel="noreferrer">2015-05-02</a>, so it's clear that this decision was intentional and well-justified.  But, so far, I haven't found that justification and suspect that it may have been decided at in-person meetings.  So I'm hopping someone knows.]</p>
  <p>Finally, I also wonder <em>how</em> the LHS is flattened, at a conceptual level.  (I don't mean in the Rakudo implementation specifically; I mean as a mental model).  Here's how I'd been thinking about binding versus list assignment:</p>
  <pre class="lang-raku prettyprint-override"><code>my ($a, :$b) := (4, :a(2)); # Conceptually similar to calling .Capture on the RHS
  my ($c, $d, $e);
  ($c, ($d, $e) = (0, 1, 2);  # Conceptually similar to calling flat on the LHS
  </code></pre>
  <p>Except that <em>actually</em> calling <code>.Capture</code> on the RHS in line 1 works, whereas calling <code>flat</code> on the LHS in line 3 throws a <code>Cannot modify an immutable Seq</code> error – which I find very confusing, given that we flatten <code>Seq</code>s all the time.  So is there a better mental model for thinking about this auto-flattening behavior?</p>
  <p>Thanks in advance for any help.  I'm trying to understand this better as part of my work to <a href="https://github.com/Raku/doc/pull/3962" rel="noreferrer">improve the related docs</a>, so any insight you can provide would support that effort.</p>