Array as an argument, ambiguous behaviour.

[Cooler]

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().