IIRC it was the same in D1, has it changed? If no, what should be used?

inout is now completely different from ref. It has been used to implement
DIP2
(http://www.prowiki.org/wiki4d/wiki.cgi?action=browse&amp;id=LanguageDevel/DIPs/D
P2&amp;oldid=DiP2).
However, the current incarnation is broken, eventually it will work.
Use ref wherever you would normally use inout in D1.
-Steve

If you start performing some experiments on your own you can write a small
program like this:
// program1
import std.stdio: writeln;
void foo(int x, in int y) {
x = 1;
y = 2;
}
void main() {
int x, y;
foo(x, y);
writeln(x, " ", y);
}
The compiler prints an error because y is seen as const. So a better question
(I don't know the answer) is: what's the purpose of "in" if now function
arguments can be const?
A related program:
// program2
import std.stdio: writeln;
void bar(out int x) {
int y = x; // line 4
writeln(y); // prints 0
}
void main() {
int x = 10;
bar(x);
writeln(x); // prints 0
}
Is this program correct? It compiles and runs, printing 0 two times. I don't
like that code. I think it's even worse than a similar C program, where the
caller must add a &x, revealing part of how x will be used by the bar()
function.
I think that in theory the line 4 is an error, because technically y is an
output variable, so it's not initialized yet. In practice it's initialized with
its init. And I think code like that program2 can easily hide bugs. This shows
why built-in tuples are good. Currently there are many holes in D2.
If you have answers or comments please let us know.
Bye,
bearophile

According to D2 semantics that program2 is correct, because in D you can use
variables that are not initialized by the programmers. But the spirit of that
program2 is trash anyway, because it reads the value of a variable that's meant
to be used as return value only, so it's meant to be written before any read.
In a situation like program2 the C# compiler prints an error like:
error CS0269: Use of unassigned out parameter `x'
Because in C# it is not allowed to use uninitialized variables. This is a so
tidy thing (bug probably such tests done by C# compiler forbids some correct
spaghetti code that D doesn't forbid. It's hard to find such cases in normal C#
programming).
So I think 'out' arguments are bug-prone in D. If you have tuples, you can
return one of them avoiding the need for 'out' arguments (they can even be
removed from the language), so you can avoid some possible bugs.
Bye,
bearophile

Here I prefer the C#/Java compilers, that don't initialize and turn the usage
of initialized variables into an error.

(at function entrance I guess).<

Yes. But you have seen in my program2 the variable x is initialized to 10 in
the main program. This is a bit bug-prone because such value gets unused. It's
like a value written before it's overwritten by its first init value. I think
this only happens for 'out' arguments.

According to D2 semantics that program2 is correct, because in D you can
use variables that are not initialized by the programmers.
...
Because in C# it is not allowed to use uninitialized variables.

D's general approach is to initialize every variable and only allow
unintialized ones with explicit "= void"
And that's good behavior imho.
So "out parameters are set to the default initializer for the type of it"
(at function entrance I guess).

So I think 'out' arguments are bug-prone in D. If you have tuples, you
can return one of them avoiding the need for 'out' arguments