> [&] is handy indeed yet this was motivated by my experience in legacy heavy codebases where there are often many variables in scope and some with external con

> [&] is handy indeed yet this was motivated by my experience in legacy heavy codebases where there are often many variables in scope and some with external consequences (e.g. file descriptors, sockets). I don't want these accidentally captured if the lambda invocation site has lifetime implications beyond those resources. I think your solution to that problem goes the wrong way, though. The problem is whether or not a lambda can survive past the immediate usage, not what it captures. Listing those resources explicitly still gives you the same bug, banning [&] didn't avoid it. I'd suggest instead an approach where a template taking a callable annotates whether or not it's "inline". If it is inline, then [&] should just be the default even. If it's not, then ban [&]. Possibly ban taking anything by reference if it's not a synchronously-used lambda even. (inline / non-inline terms here cribbed from Kotlin https://kotlinlang.org/docs/inline-functions.html https://kotlinlang.org/docs/inline-functions.html - probably there's a better word for it, but whatever)