On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
> If I use fun2() I expect that fun2() will change the content of my array, and all changes I will see. If I don't want any change to my array, I will use fun1(). What should I want to use fun3()?

For changes to content of array but not array itself.

On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
> On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
>> What should I want to use fun3()?
>
> For changes to content of array but not array itself.

For zillion+nth time :)

On Thursday, 30 January 2014 at 14:18:41 UTC, Cooler wrote:
> "But I would point out that fun2 does not guarantee anything more than fun3:" - fun2() cannot guarantee anything because it calls fun3() which in turn cannot guarantee anything.

Unrelated.

void foo2(ref int[] arr)
{ /* do nothing */ }

You can't guarantee mutation by function signature. Well, unless compiler does full attribute and qualifier inference.

On Thu, 30 Jan 2014 09:18:40 -0500, Cooler <kulkin@hotbox.ru> wrote:

> Forgot to mention :)
>
>>> 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);
>>> }
> "But I would point out that fun2 does not guarantee anything more than fun3:" - fun2() cannot guarantee anything because it calls fun3() which in turn cannot guarantee anything.

Right, but you said this:

> fun2(a); // Guaranteed that we will see any change to "a", made in fun2()

Which is false. That was my point.

-Steve

On Thu, 30 Jan 2014 09:07:14 -0500, Cooler <kulkin@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

On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
> On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
>> If I use fun2() I expect that fun2() will change the content of my array, and all changes I will see. If I don't want any change to my array, I will use fun1(). What should I want to use fun3()?
>
> For changes to content of array but not array itself.

I agree. I just want that the case can be expressed in language syntax more obvious - something like "fun(int[] const x){}" to emphasize that I understand that fun() can change content of array, and cannot change the {pointer,size} pair.

On Thu, 30 Jan 2014 10:24:14 -0500, Cooler <kulkin@hotbox.ru> wrote:

> On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
>> On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
>>> If I use fun2() I expect that fun2() will change the content of my array, and all changes I will see. If I don't want any change to my array, I will use fun1(). What should I want to use fun3()?
>>
>> For changes to content of array but not array itself.
>
> I agree. I just want that the case can be expressed in language syntax more obvious - something like "fun(int[] const x){}" to emphasize that I understand that fun() can change content of array, and cannot change the {pointer,size} pair.

That's what fun(int[] x) does :)

-Steve

On Thursday, 30 January 2014 at 15:29:50 UTC, Steven Schveighoffer wrote:
> On Thu, 30 Jan 2014 10:24:14 -0500, Cooler <kulkin@hotbox.ru> wrote:
>
>> On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
>>> On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
>>>> If I use fun2() I expect that fun2() will change the content of my array, and all changes I will see. If I don't want any change to my array, I will use fun1(). What should I want to use fun3()?
>>>
>>> For changes to content of array but not array itself.
>>
>> I agree. I just want that the case can be expressed in language syntax more obvious - something like "fun(int[] const x){}" to emphasize that I understand that fun() can change content of array, and cannot change the {pointer,size} pair.
>
> That's what fun(int[] x) does :)
>
> -Steve

Again...
void fun(int[] x){ x ~= 5; }
auto a = new int[10];
fun(a); // Can you predict the content of 'a'?

In your case:
void fun(int[] x){ x = [1, 2]; } // Compilation ok. Implementation's error.
The fun() implementer made error and think that caller will get new array. But it will get it only at runtime!
If we for example (just for example) have
void fun(int[] const x){ x = [1, 2]; } // Compilation error.

On Thursday, 30 January 2014 at 15:49:35 UTC, Cooler wrote:
>>> I agree. I just want that the case can be expressed in language syntax more obvious - something like "fun(int[] const x){}" to emphasize that I understand that fun() can change content of array, and cannot change the {pointer,size} pair.
>>
>> That's what fun(int[] x) does :)
>>
>> -Steve
>
> Again...
> void fun(int[] x){ x ~= 5; }
> auto a = new int[10];
> fun(a); // Can you predict the content of 'a'?


It's [0, 0, 0, 0, 0, 0, 0, 0, 0, 0].

On Thursday, 30 January 2014 at 15:51:44 UTC, Tobias Pankrath wrote:
> On Thursday, 30 January 2014 at 15:49:35 UTC, Cooler wrote:
>>>> I agree. I just want that the case can be expressed in language syntax more obvious - something like "fun(int[] const x){}" to emphasize that I understand that fun() can change content of array, and cannot change the {pointer,size} pair.
>>>
>>> That's what fun(int[] x) does :)
>>>
>>> -Steve
>>
>> Again...
>> void fun(int[] x){ x ~= 5; }
>> auto a = new int[10];
>> fun(a); // Can you predict the content of 'a'?
>
>
> It's [0, 0, 0, 0, 0, 0, 0, 0, 0, 0].

No!!! It depends how runtime allocates memory for the array. Read http://dlang.org/d-array-article.html.
If 'a' has internal space enough to place '5' the caller will see
[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5].