On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:

> Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()?

Gosh. To allow the function to modify the contents, but not the size of the array.

On Wednesday, 29 January 2014 at 16:36:44 UTC, Stanislav Blinov
wrote:
> On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:
>
>> Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()?
>
> Gosh. To allow the function to modify the contents, but not the size of the array.

Сам то понял чего написал??? :)

On Wednesday, 29 January 2014 at 16:54:27 UTC, Cooler wrote:
> On Wednesday, 29 January 2014 at 16:36:44 UTC, Stanislav Blinov
> wrote:
>> On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:
>>
>>> Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()?
>>
>> Gosh. To allow the function to modify the contents, but not the size of the array.
>
> Сам то понял чего написал??? :)

Yes I did.

On Wednesday, 29 January 2014 at 14:48:12 UTC, Cooler wrote:
>> 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.
>
> That exactly what am i asking for!
> You have to know the body of fun3() to predict what happened with 'a'.
> When I call fun() there are 3 intentions:
> 1. I want just send the contents of 'a' to fun(). It can be done by a.dup, or you must sure that fun() has 'in' qualifier for it's argument.
> 2. I want fun() change content of 'a' array. This can be done by ensuring fun() has 'ref' qualifier for it's argument.
> What intention should I have to call fun3()?

E.g. you want fun3 to change the content of the array, but you don't want it to change the pointer.

Consider,

void fun2(ref int[] x)
{
   x = null;
}

void fun3(int[] x)
{
   x = null;
}

void main()
{
   int[] a = [1, 2, 3];
   fun3(a);
   assert(a);
   fun2(a);
   assert(!a);
}

On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:
> Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()?

Where argument has the same length? After function call, or
inside function? I don't understand what my intention should be
to push me to use fun3()?

int[] a = [1,2,3]; // length == 3
fun3(a);
assert(a.length == 3); // holds.

If you have fun1 and fun2 you might have no use case for fun3. That is however no reason to disallow fun3, especially since there are situations where you don't won't to have fun2.

Keep in mind, that I'm only arguing against a ban of fun3 and the notion that it's behaviour is more unpredictable then fun2 although it offers stronger guarantees.

On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote:
> On Wednesday, 29 January 2014 at 16:15:36 UTC, Tobias Pankrath wrote:
>> On Wednesday, 29 January 2014 at 16:01:08 UTC, Cooler wrote:
>>>
>>> Do you read my post? I am answering... why do I need fun3() if I already have fun1() and fun2().
>>
>> fun3 guarantees that the argument has the same length for example.
>
> Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()?

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.

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

On Thursday, 30 January 2014 at 09:14:43 UTC, Cooler wrote:

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

Goodness... You've been shown this use case like a zillion times already: the caller manages her buffer, fun3() is allowed to change contents, but not reallocate caller's buffer.

fun1() can't provide that (const), fun2() cannot either, because it explicitly allows reallocation (ref). This behavior is only provided by fun3().

So it's either that, or indeed cases of "I don't care about this array", which Maxim Fomin has mentioned.

On Thursday, 30 January 2014 at 09:26:56 UTC, Stanislav Blinov wrote:
> On Thursday, 30 January 2014 at 09:14:43 UTC, Cooler wrote:
>
>> 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()?
>
> Goodness... You've been shown this use case like a zillion times already: the caller manages her buffer, fun3() is allowed to change contents, but not reallocate caller's buffer.
>
> fun1() can't provide that (const), fun2() cannot either, because it explicitly allows reallocation (ref). This behavior is only provided by fun3().
>
> So it's either that, or indeed cases of "I don't care about this array", which Maxim Fomin has mentioned.

May be I am dumb...
If "I don't care about this array", I can use any of fun1() or fun2().

Can you formulate contract to fun3()? Something like "Change content of an array, but if you need to change the size - don't do it!" Do you think so?

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