https://issues.dlang.org/show_bug.cgi?id=5007
--- Comment #7 from [email protected] --- If you have to refactor and clean up some old C/D code you can use a tool (like an IDE) that tags every function with the appropriate @outer(), that specifies what every function reads/writes/readwrites from outer scopes. Then with this information it's quite simpler to understand what every function does, and pass some of those globals as function arguments, move some globals inside functions, etc. For performance critical functions you sometimes don't want to pass all data a function uses, but in most cases you can remove globals, pass down values through arguments, make them constant, put them as class/struct instance values, etc. So @outer() is a tool to increase code readability, help refactor code, make code safer and keep still some globals for efficiency in a safer way. Not all code is fit for @outer(), you probably don't want to use it for small D script-like programs or in other situations, but for some situations, like when you need higher integrity code, or you need to refactor legacy code, it seems an useful improvement for D. And it's a pure addition, it breaks no existing D code. Optionally some kind of annotation or switch could be used to require all functions and nested functions of a module or package to have a @outer annotation. --
