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/dxqxlhyhmdfuashhm...@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.
