Array as an argument, ambiguous behaviour.

[Cooler]

>> Please understand - I am not against void foo(int[] x){}
>
> From an earlier post by you:
>
>> May be just prohibit at language level the case of fun3() 
>> function, to do not allow unpredictable behavior?
>
> I thought that this meant you were against it?
That was the question with "May be..." at the beginning.
>
>> I am for predictability of behavior. You suggest to describe 
>> function's behavior in documentation - quotation from your 
>> article "It is a good idea to note in the documentation how 
>> the passed in slice might or might not be
>> overwritten." My idea is that all potential errors must be 
>> detected as soon as possible.
>
> You cannot eradicate all errors. The intentions of a function 
> are not apparent to the compiler. Maybe the intention is to use 
> the argument as a buffer, and the caller should not care what 
> happens to the buffer inside the function.
>
> Adding yet another attribute is going to increase language 
> complexity for almost no benefit. It does not guarantee 
> unambiguity because you have no idea what the author of the 
> function is going to do.
>
>> The D principle - "The program compile and runs as expected, 
>> or not compile at all".
>
> This is a fantasy. The compiler cannot know what you expect.
The language is needed to express your intentions to the 
compiler. The language should be expressive as possible. My point 
is to push programmers to write correct software. I just ask 
these forum to think about topic. If everybody satisfied by void 
fun(int[] x){} behavior, then I just go...
But I encounter a bug in my program that was due to my misusing 
of such signature.

>
>> If you really need to call function that can change content of 
>> an array, but cannot change size of an array the language 
>> syntax should allow express it in function signature. I 
>> consider "void fun(int[] const x){}" more error prone than 
>> "void fun(int[] x){}" and for the caller and for implemeter.
>
> Not sure if something is mixed up there. I think void fun(int[] 
> x) is sufficient to describe what you say. The function cannot 
> alter x's array bounds at all, and can alter it's data.
>
Here is the reason why i post the topic on this forum. You think 
one way, I think another way. I wanted to discuss what think 
other people. But looks like still nobody can understand my 
point, or may be I cannot express it...

>>
>>> I see very little value in that. We don't need to obliterate 
>>> a tremendous  amount of slice usage (not mentioning how much 
>>> code will have to be  updated) in order to help newbies 
>>> understand how slices work.
>> Any idea can be rejected by this sentence.
>
> No, only ideas that force people to change millions of lines of 
> code, and provide scant benefits instead of taking 5 minutes to 
> explain "no, just use x[0..2] = [1, 2]" or "just use ref int[] 
> x" depending on the goal.
>
> -Steve