> If, however, in fun3 you change the size of the array - it may reallocate. Like, if you're appending to `x` - it will allocate a new array and make x point to it. Now `a` and `x` point to distinct arrays. And any change you do using `x` won't be seen by `a`. And, yes, this is the intended behavior.

That exactly what am i asking for!
You have to know the body of fun3() to predict what happened with 'a'.
When I call fun() there are 3 intentions:
1. I want just send the contents of 'a' to fun(). It can be done by a.dup, or you must sure that fun() has 'in' qualifier for it's argument.
2. I want fun() change content of 'a' array. This can be done by ensuring fun() has 'ref' qualifier for it's argument.
What intention should I have to call fun3()?

> Yes, that is how slices work in D. The following article explains the "non-determinism" that you mention:
>
>   http://dlang.org/d-array-article.html
>
> Ali

Thank you for the article.
Quotation from the article "It is a good idea to note in the documentation how the passed in slice might or might not be overwritten."
May be just prohibit at language level the case of fun3() function, to do not allow unpredictable behavior?

On Wednesday, 29 January 2014 at 15:11:33 UTC, Cooler wrote:
>> Yes, that is how slices work in D. The following article explains the "non-determinism" that you mention:
>>
>>  http://dlang.org/d-array-article.html
>>
>> Ali
>
> Thank you for the article.
> Quotation from the article "It is a good idea to note in the documentation how the passed in slice might or might not be overwritten."
> May be just prohibit at language level the case of fun3() function, to do not allow unpredictable behavior?

It's not unpredictable, at least not more unpredictable then fun2.

Should we dissallow this two?

int[] a = [1,2,3,4];
b = a;
b ~= [5, 6, 7, 8];

On Wednesday, 29 January 2014 at 15:11:33 UTC, Cooler wrote:
>> Yes, that is how slices work in D. The following article explains the "non-determinism" that you mention:
>>
>>  http://dlang.org/d-array-article.html
>>
>> Ali
>
> Thank you for the article.
> Quotation from the article "It is a good idea to note in the documentation how the passed in slice might or might not be overwritten."
> May be just prohibit at language level the case of fun3() function, to do not allow unpredictable behavior?

This behavior is just a consequence of the deliberate decision on how arrays should be implemented.

Any decision would be a trade-off. Like, if you just disallow this signature, you will have to use .dup at the caller side if you want the semantics of fun3. And often this copy might be unnecessary.

It's really like a ball under the carpet. You make it flat in one place, but the ball pops up in the other.

The trade-off that D chooses is pretty reasonable. You just have to accept that and get used to it.

> It's not unpredictable, at least not more unpredictable then fun2.
>
> Should we dissallow this two?
>
> int[] a = [1,2,3,4];
> b = a;
> b ~= [5, 6, 7, 8];

You don't understand me. You consider that I am author of the fun() and the caller side.
Read two post above http://forum.dlang.org/post/dxqxlhyhmdfuashhmtrz@forum.dlang.org

I consider that author of fun() and author of caller side are different persons. They must agree between them how to provide some functionality.
If I fun()'s author why do I need to provide fun3() if I already provided fun1() and fun2()?
I I caller's author - why may I require fun3() variant, if I already have fun1() and fun2()?

>
> This behavior is just a consequence of the deliberate decision on how arrays should be implemented.
>
> Any decision would be a trade-off. Like, if you just disallow this signature, you will have to use .dup at the caller side if you want the semantics of fun3. And often this copy might be unnecessary.
>
> It's really like a ball under the carpet. You make it flat in one place, but the ball pops up in the other.
>
> The trade-off that D chooses is pretty reasonable. You just have to accept that and get used to it.

Ok! I agree with you! Can you just answer me http://forum.dlang.org/post/dxqxlhyhmdfuashhmtrz@forum.dlang.org

On Wednesday, 29 January 2014 at 15:38:34 UTC, Cooler wrote:
>> It's not unpredictable, at least not more unpredictable then fun2.
>>
>> Should we dissallow this two?
>>
>> int[] a = [1,2,3,4];
>> b = a;
>> b ~= [5, 6, 7, 8];
>
> You don't understand me. You consider that I am author of the fun() and the caller side.
> Read two post above http://forum.dlang.org/post/dxqxlhyhmdfuashhmtrz@forum.dlang.org
>
> I consider that author of fun() and author of caller side are different persons. They must agree between them how to provide some functionality.
> If I fun()'s author why do I need to provide fun3() if I already provided fun1() and fun2()?
> I I caller's author - why may I require fun3() variant, if I already have fun1() and fun2()?

Oh, I guess I understood quite well. I just don't see a special problem with arrays, it's just the same as any other aliasing issue. Take this for example:

void funS(S* s); // S is a struct, maybe containing a ptr and a length member :-)

Should we disallow this as well? When I give a unqualified pointer to a function, the only guarantee I get is that it's pointing to the same location after the call. It's the same with arrays.

And since we have this problem every time we pass a pointer to function I don't see why arrays should get special treatment.

On Wednesday, 29 January 2014 at 15:56:50 UTC, Tobias Pankrath wrote:
> On Wednesday, 29 January 2014 at 15:38:34 UTC, Cooler wrote:
>>> It's not unpredictable, at least not more unpredictable then fun2.
>>>
>>> Should we dissallow this two?
>>>
>>> int[] a = [1,2,3,4];
>>> b = a;
>>> b ~= [5, 6, 7, 8];
>>
>> You don't understand me. You consider that I am author of the fun() and the caller side.
>> Read two post above http://forum.dlang.org/post/dxqxlhyhmdfuashhmtrz@forum.dlang.org
>>
>> I consider that author of fun() and author of caller side are different persons. They must agree between them how to provide some functionality.
>> If I fun()'s author why do I need to provide fun3() if I already provided fun1() and fun2()?
>> I I caller's author - why may I require fun3() variant, if I already have fun1() and fun2()?
>
> Oh, I guess I understood quite well. I just don't see a special problem with arrays, it's just the same as any other aliasing issue. Take this for example:
>
> void funS(S* s); // S is a struct, maybe containing a ptr and a length member :-)
>
> Should we disallow this as well? When I give a unqualified pointer to a function, the only guarantee I get is that it's pointing to the same location after the call. It's the same with arrays.
>
> And since we have this problem every time we pass a pointer to function I don't see why arrays should get special treatment.

Do you read my post? I am answering... why do I need fun3() if I already have fun1() and fun2().

On Wednesday, 29 January 2014 at 16:01:08 UTC, Cooler wrote:
>
> Do you read my post? I am answering... why do I need fun3() if I already have fun1() and fun2().

fun3 guarantees that the argument has the same length for example.

On Wednesday, 29 January 2014 at 16:15:36 UTC, Tobias Pankrath wrote:
> On Wednesday, 29 January 2014 at 16:01:08 UTC, Cooler wrote:
>>
>> Do you read my post? I am answering... why do I need fun3() if I already have fun1() and fun2().
>
> fun3 guarantees that the argument has the same length for example.

Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()?