Array as an argument, ambiguous behaviour.

[Cooler]

> 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.
One of the main idea of D is that things must work as planned, or 
would not compile at all. First and second variants follow this 
idea. But fun3() can work not as planned on the caller side 
(depends on fun3() body's implementation).
The question again - may be prohibit fun3() variant? If we 
prohibit it, what use cases we could not implement with fun1() 
and fun2()?