&gt; You only talk about the memory management part and I guess most language designers think the same. What you and they fail to account for is that explicit capture list can reduce logical bugs.<p>I suppose, as a language designer, I tend to think that the more I do automatically, the more I ease the programmer&#x27;s burden.  However, as you point out, that&#x27;s not always true.  That said, my point wasn&#x27;t (isn&#x27;t?) that explicit capture is only a good idea sans automatic memory management (it may well be -- you&#x27;ve certainly given me some food for thought here), but rather that it&#x27;s only <i>necessary</i> in that case, and I think that point still stands.<p>&gt; For one, if I were allowed to explicitly capture the counter variable by copy, the surprising behavior mentioned above would never occur.<p>That&#x27;s a failure of language design and I don&#x27;t think the proper solution is to force explicit capture on closure creation (also note that you need <i>more</i> than just explicit capture because to prevent such an error, you need the ability to specify that the &quot;captured&quot; variable ought to be copied rather than actually captured).  I think the proper solution to that problem is the one that the C# team went with:  limit the scope of iteration control variables to the iterated block.  This is typically what programmers used to block-structured languages would expect, anyway, unless the variable were clearly declared outside the scope of the iteration.<p>&gt; In languages with mutability, the ability to make some part immutable is a virtue.<p>That&#x27;s an orthogonal issue, and can be done in many other (and more general) ways.<p>&gt; For two, in languages without explicit variable declaration, which variable is defined where quickly becomes murky when you have implicit capture. I have so many frustrations where the inner `i` variable clashes with the outer `i` in Python. Yes, I could just use a different name, but naming is hard, and with a new scope I should be able to reuse the name. That is almost the whole point of opening a new scope!<p>You&#x27;re right:  that <i>is</i> the point of opening a new scope!  That sounds like a flaw in Python&#x27;s design and could be remedied by making variable definition syntax different from assignment syntax.  Consider Lua with its `local` syntax, C and kin with their type annotations, the Lisps with their completely separate forms for variable definition and assignment, and so on.  There&#x27;s also the Tcl strategy of &quot;it&#x27;s a definition unless it was imported into this scope with `global` or `upval`;  otherwise it&#x27;s an assignment&quot;.<p>&gt; For three, in Javascript where closures are everywhere due to the amount of callbacks, the reference graph is just impossible to analyze. A closure may closes over another closure which closes over an object with a reference to the original closure. An explicit capture list makes the programmer think, and ease the job of anyone who tries to spot memory leaks from the source code. (But I guess that is just not the Javascript style, as they are so fond of never letting the programmers know about their mistakes. At least in C++ we trade that for speed. I don&#x27;t know what Javascript trades that for.)<p>JavaScript is a shitty language to begin with, and fixing it wouldn&#x27;t be as simple as fixing C# or Python...  You make a good point here, but I still think that better tooling for data-flow analysis is a more attractive choice than a compulsory explicit capture list.  On the flip side, an optional capture list could be a good compromise.