Array as an argument, ambiguous behaviour.

[Steven Schveighoffer]

On Thu, 30 Jan 2014 12:38:57 -0500, Cooler <kulkin at hotbox.ru> wrote:


>>> 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?

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

> 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