Array as an argument, ambiguous behaviour.

[Steven Schveighoffer]

On Thu, 30 Jan 2014 09:07:14 -0500, Cooler <kulkin at hotbox.ru> wrote:

> If I don't want that fun() will change my array, i have to use fun1()  
> variant.
> If I want fun() will change my array, i have to use fun2() variant. What  
> fun2() do with it's argument inside it's body - not my business.

No. You can use fun3 variant as well:

void fun3(int[] x)
{
    x[] = 0; // guaranteed to be seen by caller.
}

>
> 1. For example somebody already implemented fun1() and fun2() variants,  
> as in my first post. This variants understandable and predictable. What  
> can push me to ask another person for fun3() implementation, while it  
> result is unpredictable, until you know fun3() body?

The only reason to have both fun2 and fun3 variants is if you want to  
handle both l-value and r-value options differently. There would be very  
few use cases which make sense AND return void.

You usually want one or the other.

>
> 2. You wrote "If your code must do otherwise, explain in the  
> documentation what
> should happen". That exactly what I am trying to discuss here. Instead  
> of writing some documentation, just warn (and may be prohibit in far-far  
> future) about such possible unpredictability during compilation.

No, because you are not understanding the effect of the attributes, and  
who is responsible for what.

1. Banning such signatures does NOT accomplish what you want.
2. Such signatures do NOT guarantee what happens inside the function.

Having the compiler ban the problem where you expect the caller to see  
your changes, but they don't, is akin to just making the compiler able to  
detect all logic bugs. It's not possible (NP complete). The compiler just  
doesn't know what you really want to do.

-Steve