Array as an argument, ambiguous behaviour.

Maxim Fomin maxim at maxim-fomin.ru
Thu Jan 30 02:19:33 PST 2014


On Thursday, 30 January 2014 at 09:14:43 UTC, Cooler wrote:
>> If you want to modify the slice and make changes visible in 
>> caller, you should use ref. If you don't care whether changes 
>> are visible in caller, you can omit any attributes and use 
>> plain array. This belongs to the case you are asking about. If 
>> you don't want to change array in callee, pass it as const 
>> qualified.
>>
>> Now, after rethinking the issue I am inclining that "don't 
>> care whether changes are visible for caller" is not very 
>> wrong, but not very good design. Ideally it should be 
>> specified to avoid unexpected problems to pop up. So yes, it 
>> is better to qualify array.
>>
>> Another point. This casino games of whether changes would be 
>> visible or not is direct consequence of how slices are 
>> implemented (and how runtime service them). Remember, that 
>> many features in D work in a strange way not because of wise 
>> design but as a consequence of not fully thought design (like 
>> array). As a result, some features work in not best way they 
>> should. Although many folks in newsgroups would eagerly say 
>> that you don't understand the lang, it wouldn't make a bad 
>> design a good one.
>
> Please stop explain me how fun3() works. I know that.

This is first problem. You are being explained what is the 
*purpose* of the fun3() but you repeatedly fail to accept it.

> One of the main idea of D is that things must work as planned, 
> or would not compile at all.

Outcryingly wrong. Study bugzilla which shows how some things go 
wrong and read DIPs to learn that there are some issues in the 
language for which the communitty still struggles to formulate 
good solution.

> First and second variants follow this idea. But fun3() can work 
> not as planned on the caller side (depends on fun3() body's 
> implementation).

Many things can work not as intended. Please read forums, 
bugzilla, etc. I bet passing array will not be the only thing you 
find confusing.

> The question again - may be prohibit fun3() variant?

Prohibiting code like:
void foo(int[] arr) {}

would break hell of a code and pose doubts on what happens with 
arrays if so simple construction is prohibited. In addition, I 
mentioned that "don't care" is probably sometimes an option. 
Emitting warning here has some merits but it would be consitently 
ignored (I expect).


More information about the Digitalmars-d-learn mailing list