Inout unclearness

Max Klimov via Digitalmars-d digitalmars-d at puremagic.com
Sat Jul 11 22:03:13 PDT 2015


I have some questions about "inout" qualifier. I treated this 
qualifier as duplicated code reducer without using templates. But 
it is a real part of type system with its own casting rules. 
Inside an inout function we have special type "inout(T)" with 
several restrictions. So the first question is: should I keep in 
mind that my generalized code can meet inout type and how to work 
with it?

For example, I have problems with the following code that, I 
suppose, should work.

class A {}

A foo(A x) // works
{
     Rebindable!(typeof(return)) r;
     r = x;
     return r;
}

const(A) foo(const(A) x) // works
{
     Rebindable!(typeof(return)) r;
     r = x;
     return r;
}

immutable(A) foo(immutable(A) x) // works
{
     Rebindable!(typeof(return)) r;
     r = x;
     return r;
}

inout(A) bar(inout(A) x) // compilation error
{
     Rebindable!(typeof(return)) r;
     r = x;
     return r;
}

Rebindable doesn't handle the case of inout type and I don't 
think that it can do it because it is possible to cast to inout 
or to keep inout variables only inside the proper inout function. 
So, I have to make some silly workarounds with castings in this 
case. The same situation happens in several places in phobos when 
arguments type is deductible. For example, 
std.array.replaceInPlace(...), std.array.join(...), etc, can not 
be used with inout(T) parameters.

The second question: if I want to provide inout function but it 
fails like in the example above, what is common practice? Just 
use casting? Or make a templated version and provide hand-writing 
code for all cases (mutable, const, immutable)? Or something 
wrong with inout qualifier?


More information about the Digitalmars-d mailing list