Array as an argument, ambiguous behaviour.

[Tobias Pankrath]

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.