Array as an argument, ambiguous behaviour.

[Cooler]

>>>> 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.
>
> Anything that the compiler cannot enforce is just 
> documentation. Does it matter whether the documentation is in a 
> comment or part of the signature?
Why we need "const" keyword, while we can just put "I promise do 
not change it" in the documentation?

>
>> 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...
>
> I'm not trying to be a bully or anything, but you are not 
> understanding that what you want is a guarantee of logic, that 
> the compiler cannot possibly enforce.
I am telling to the compiler what to do, or what not to do, with 
help of programming language. I am controlling the compilation 
result with the language. I am not waiting that compiler will 
anticipate my thoughts. But if I write "const x" the variable 
must be const. If i have language construct that can give me 
stronger guarantees, i will use it.

> Your example (setting a variable to another value) being 
> rejected is easy to work around, just use another variable that 
> doesn't have that restriction.
My goal is not to implement some functionality, and I don't know 
how to do it.
I want to make programmer's intentions more clear with a help of 
language.
What you are saying is approximately - "If everybody will tune 
the language to his private needs, it will be not good". I agree 
with such point. Therefore I asked in the forum - am I alone who 
wants to tune this language feature? If you are experienced 
programmer in D your brain filter such cases automatically.

> There are so many examples of behavior-enforcing features that 
> result in something that the creator of the feature didn't want 
> or expect. Keep in mind there are years of projects that have 
> been written assuming that you can use a standard slice in the 
> signature of a function, we don't want to invalidate all that 
> code just because programmers sometimes write buggy code.
>
I don't even thought to invalidate already written code.

>> But I encounter a bug in my program that was due to my 
>> misusing of such signature.
>
> Here's where the gray area is. If you make this error once or 
> twice, but never again, is it worth changing the language over? 
> Probably not. But if you make this error every day, even 
> KNOWING what will happen, it's worth looking into. But any 
> changes have to avoid a negative impact on existing code as 
> much as possible. Think of the person who knows how slices 
> work, who very seldom makes this mistake, and who now has to go 
> through all his code and make this change, never finding an 
> instance where it makes a difference.
>
> At this point, I'm not sure what you are proposing, but I don't 
> think there is much value in changing the way slice passing 
> works.
>
>>>> 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...
>
> By mixed up, I meant that you seemed to be valuing the int[] x 
> version over the int[] const x version.
>
> Other than that, what I stated is an indisputable fact -- the 
> function cannot alter x's bounds.
>
> -Steve