Consider 3 functions taking array as an argument:

void fun1(in  int[] x){...}
void fun2(ref int[] x){...}
void fun3(    int[] x){...}

auto a = new int[10];

fun1(a); // Guaranteed that "a" will not be changed
fun2(a); // Guaranteed that we will see any change to "a", made in fun2()
fun3(a); // Changes to "a" in fun3() may be or may be not visible to the caller

In case of fun3() we have ambiguous behaviour, depending on the body of the function.

Am I right?
Is that intentional?

On Wednesday, 29 January 2014 at 10:55:57 UTC, Cooler wrote:
> Consider 3 functions taking array as an argument:
>
> void fun1(in  int[] x){...}
> void fun2(ref int[] x){...}
> void fun3(    int[] x){...}
>
> auto a = new int[10];
>
> fun1(a); // Guaranteed that "a" will not be changed
> fun2(a); // Guaranteed that we will see any change to "a", made in fun2()
> fun3(a); // Changes to "a" in fun3() may be or may be not visible to the caller
>
> In case of fun3() we have ambiguous behaviour, depending on the body of the function.
>
> Am I right?
> Is that intentional?

Arrays are a pair of pointer and length.

fun1 marks the pointer, the length and the data pointed as const.
fun3 marks nothing const, but since pointer and length are passed by value, you'll only see changes to the content of x.
fun2 is like fun3, but pointer and length are itself passed by reference.

Thank you for detailed explanation. But the question is - "Is that correct that language allows ambiguous behavior?"

On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
> Thank you for detailed explanation. But the question is - "Is that correct that language allows ambiguous behavior?"

Could you expand your example?

fun(int[] a) {} is passing a by value, that is, the pointer and length is copied over to fun. Any changes to the elements of a will be visible, but if you reassign a directly or indirectly (expanding it so it needs to be copied to a new memory location), the changes are not visible.

On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
> Thank you for detailed explanation. But the question is - "Is that correct that language allows ambiguous behavior?"

Where is it ambiguous?

On Wednesday, 29 January 2014 at 12:40:00 UTC, Tobias Pankrath wrote:
> On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
>> Thank you for detailed explanation. But the question is - "Is that correct that language allows ambiguous behavior?"
>
> Where is it ambiguous?

Ambiguity is here...
When I call fun1() or fun2() I know the behavior directly from function signature (read the comments in my first post). For fun3() case the caller side don't know the behavior directly from function signature. To know what will happen with array "a", the caller must see to fun3() body.
Ambiguity is - in first and second cases the caller knows what happens with "a", but in third case the caller does not know what happens with "a".

On Wednesday, 29 January 2014 at 13:15:30 UTC, Cooler wrote:
> On Wednesday, 29 January 2014 at 12:40:00 UTC, Tobias Pankrath wrote:
>> On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
>>> Thank you for detailed explanation. But the question is - "Is that correct that language allows ambiguous behavior?"
>>
>> Where is it ambiguous?
>
> Ambiguity is here...
> When I call fun1() or fun2() I know the behavior directly from function signature (read the comments in my first post). For fun3() case the caller side don't know the behavior directly from function signature. To know what will happen with array "a", the caller must see to fun3() body.
> Ambiguity is - in first and second cases the caller knows what happens with "a", but in third case the caller does not know what happens with "a".

'in' is a shorthard for 'const scope'.
'const' means that the callee cannot change the passed in parameter in any way, including anything available through that type (for example x[0])
'scope' means it cannot leave the scope of the callee - that it cannot be stored away anywhere.
'ref' means that the parameter is passed by reference, and thus might be reassigned or changed in any way.

No parameters means that it's mutable, but the reference cannot change.

I don't see any ambiguities here.

On Wednesday, 29 January 2014 at 13:15:30 UTC, Cooler wrote:
> On Wednesday, 29 January 2014 at 12:40:00 UTC, Tobias Pankrath wrote:
>> On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
>>> Thank you for detailed explanation. But the question is - "Is that correct that language allows ambiguous behavior?"
>>
>> Where is it ambiguous?
>
> Ambiguity is here...
> When I call fun1() or fun2() I know the behavior directly from function signature (read the comments in my first post). For fun3() case the caller side don't know the behavior directly from function signature. To know what will happen with array "a", the caller must see to fun3() body.
> Ambiguity is - in first and second cases the caller knows what happens with "a", but in third case the caller does not know what happens with "a".

I believe you encounter an array reallocation.

If fun3 doesn't change the size of the array - you will see every change made by fun3 to the contents of `a` (but the `a` itself cannot be changed - only the contents). No other way around.

If, however, in fun3 you change the size of the array - it may reallocate. Like, if you're appending to `x` - it will allocate a new array and make x point to it. Now `a` and `x` point to distinct arrays. And any change you do using `x` won't be seen by `a`. And, yes, this is the intended behavior.

On Wednesday, 29 January 2014 at 13:38:22 UTC, simendsjo wrote:
> On Wednesday, 29 January 2014 at 13:15:30 UTC, Cooler wrote:
>> On Wednesday, 29 January 2014 at 12:40:00 UTC, Tobias Pankrath wrote:
>>> On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
>>>> Thank you for detailed explanation. But the question is - "Is that correct that language allows ambiguous behavior?"
>>>
>>> Where is it ambiguous?
>>
>> Ambiguity is here...
>> When I call fun1() or fun2() I know the behavior directly from function signature (read the comments in my first post). For fun3() case the caller side don't know the behavior directly from function signature. To know what will happen with array "a", the caller must see to fun3() body.
>> Ambiguity is - in first and second cases the caller knows what happens with "a", but in third case the caller does not know what happens with "a".
>
> 'in' is a shorthard for 'const scope'.
> 'const' means that the callee cannot change the passed in parameter in any way, including anything available through that type (for example x[0])
> 'scope' means it cannot leave the scope of the callee - that it cannot be stored away anywhere.
> 'ref' means that the parameter is passed by reference, and thus might be reassigned or changed in any way.
>
> No parameters means that it's mutable, but the reference cannot change.
>
> I don't see any ambiguities here.

Don't anybody understand me?!

I know what means "in" and "ref" qualifiers!

> No parameters means that it's mutable, but the reference cannot change.
Here is ambiguity.
void fun3(int[] x){ x ~= 5; ... }
auto a = new int[10];
fun3(a); // Here content of "a" may be changed or may be not changed. Depends on the buffer size that system will allocate for "a" array.

On 01/29/2014 02:55 AM, Cooler wrote:
> Consider 3 functions taking array as an argument:
>
> void fun1(in  int[] x){...}
> void fun2(ref int[] x){...}
> void fun3(    int[] x){...}
>
> auto a = new int[10];
>
> fun1(a); // Guaranteed that "a" will not be changed
> fun2(a); // Guaranteed that we will see any change to "a", made in fun2()
> fun3(a); // Changes to "a" in fun3() may be or may be not visible to the
> caller
>
> In case of fun3() we have ambiguous behaviour, depending on the body of
> the function.
>
> Am I right?
> Is that intentional?

Yes, that is how slices work in D. The following article explains the "non-determinism" that you mention:

  http://dlang.org/d-array-article.html

Ali