• Jarrett Billingsley (51/51) Jan 28 2006 I've noticed one shortcoming of out and inout parameters - you can't set...
• Walter Bright (5/8) Jan 28 2006 For those cases, I think one should stick with "in int* x". After all, x...

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

I've noticed one shortcoming of out and inout parameters - you can't set 
them to a value that means "no output."

By that,  I mean that in C and C++, if you want to return a value in a 
parameter, you usually use a pointer, like so:

void fork(int* x)
{
    if(x != NULL)
        (*x) = 5;
}

That way, if you don't want to get a value put into that parameter you pass 
in NULL.

In D, there are out and inout for returning parameters (well really only 
out, but you can use inout as well).

void fork(out int x)
{
    x = 5;
}

The problem here is - what if you don't want a return value in that 
parameter?  What can you pass in to make it not set x to a value?  You end 
up using either a flag:

void fork(out int x, bit getX = 1)
{
    if(getX)
        x = 5;
}

Or you use pointers, as above, and just check for null.

This is a trivial function, but there are cases when it'd be nice to have 
"optional" inout and out parameters.  For example, in a load method for a 
complex file, if you only want to load certain parts of the file, you could 
set the parts that you don't want to load to null.

What I was thinking was this.  All out and inout parameters really are are 
implicit indirection.  If you get the address of an out or inout param in a 
function, it will give you the pointer to the variable that was passed into 
that parameter.  Thus, all that would have to happen, would be this: allow 
the constant "null" to be passed into out/inout params.  Then, a check like 
so could be performed:

void fork(out int x)
{
    if(&x !is null)
        x = 5;
}

So calling

fork(null)

Would mean that the assignment would be skipped in the function, as the 
address of x in the function would be null.

The only problem I see with this is that current out/inout functions would 
have to be retrofitted to check for null params, which might not go over 
well.

Another solution would be to introduce this as a new feature with a slightly 
different syntax, such as "inout void int x," meaning that x can be null, 
while "inout int x" would fail if you tried to pass null into it. 

"Walter Bright" <newshound digitalmars.com> writes:

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:drgn05$28a1$1 digitaldaemon.com...
 Another solution would be to introduce this as a new feature with a 
 slightly different syntax, such as "inout void int x," meaning that x can 
 be null, while "inout int x" would fail if you tried to pass null into it.

For those cases, I think one should stick with "in int* x". After all, x 
really is being used as an in parameter because its value is being tested, 
not as an out or inout.