Array as an argument, ambiguous behaviour.

Steven Schveighoffer schveiguy at yahoo.com
Thu Jan 30 05:44:39 PST 2014


kOn Wed, 29 Jan 2014 05:55:56 -0500, Cooler <kulkin at hotbox.ru> wrote:

> Consider 3 functions taking array as an argument:
>
> void fun1(in  int[] x){...}
> void fun2(ref int[] x){...}
> void fun3(    int[] x){...}
>
> auto a = new int[10];
>
> fun1(a); // Guaranteed that "a" will not be changed
> fun2(a); // Guaranteed that we will see any change to "a", made in fun2()
> fun3(a); // Changes to "a" in fun3() may be or may be not visible to the  
> caller
>
> In case of fun3() we have ambiguous behaviour, depending on the body of  
> the function.
>
> Am I right?

Yes.

> Is that intentional?

Yes.

I read the rest of the discussion. Arrays are hard to understand in D,  
especially if you have preconceived notions from other languages. But I  
would point out that fun2 does not "guarantee" anything more than fun3:

void fun2(ref int [] x)
{
    fun3(x);
}

It is an intrinsic property of slices that they do not own the data  
pointed at. You cannot guarantee that one slice's changes will affect  
another slice, AS LONG AS one slice is increasing its length. If you avoid  
increasing the length, then the results are deterministic. As I said in  
the article, avoid increasing the length, and THEN changing the original  
data. If you do that, you should have quite predictable results. If your  
code must do otherwise, explain in the documentation what should happen  
(i.e. don't use the passed-in slice after the function), and use some of  
the tricks to avoid it (use ref, or return the new slice data).

-Steve


More information about the Digitalmars-d-learn mailing list