Array as an argument, ambiguous behaviour.

Steven Schveighoffer schveiguy at yahoo.com
Thu Jan 30 09:07:30 PST 2014


On Thu, 30 Jan 2014 11:48:50 -0500, Cooler <kulkin at hotbox.ru> wrote:

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

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

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

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


More information about the Digitalmars-d-learn mailing list