https://issues.dlang.org/show_bug.cgi?id=5007

--- Comment #7 from bearophile_hugs@eml.cc ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=5007

--- Comment #8 from bearophile_hugs@eml.cc ---
Walter Bright has commented on @outer():

> I suggest using 'pure' and passing the globals you actually need as ref parameters.

This is what I usually do in D, but it has some small disadvantages:
- It increases the number of function arguments (they are 8 bytes
each), increasing the size of the function, adding some stack
management instructions. This slows the function a little, if the
function is performance-critical.
- Sometimes you can't use "pure", for various reasons, like
Phobos functions not yet pure, I/O action in your function, or
other causes.
- If your pure function foo receives two global argument as out
and ref, the function bar that calls it needs to access to global
variables or it too needs those two ref/out arguments. The
current design of @outer() is not transitive, so only foo needs
to state what global variables are in/out/inout.
- @outer is more DRY, because you don't need to specify the type
of the global variable received by ref, you just need to know its
name.
- With @outer you can tighten some old code, without changing the
signature of a function. If you have an old D module (or a C
function converted to C) you often can't (or you don't want) to
change the function signature to add the global arguments passed
by ref. With @outer() the function signature doesn't change, so
you can improve your legacy code. It allows a simpler refactoring
of code.

More notes:
- SPARK language has added a feature similar to @outer, but more
verbose. See comment 5.
- @outer() is optional and it's fiddly because not it's not meant
for small D script-like programs, it's meant as a help for
medium-integrity D programs (where you may think about using Ada
language instead).

--

https://issues.dlang.org/show_bug.cgi?id=5007

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--