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