Am 15.04.2014 13:23, schrieb monarch_dodra:
> On Tuesday, 15 April 2014 at 06:31:02 UTC, Andrei Alexandrescu wrote:
>> We've just enabled warnings as errors in our build system at work and
>> suddenly:
>>
>> Warning: explicit element-wise assignment <exprnew> is better than <expr>
>>
>> where <exprnew> and <expr> are expressions picked from the code. For
>> example, this wasn't accepted:
>>
>> writeAvail_[0 .. buf.length] = buf;
>>
>> but this was:
>>
>> writeAvail_[0 .. buf.length] = buf[];
>>
>> The type of the involved variables were as trivial as ubyte[] and in
>> ubyte[] respectively.
>>
>> What's the idea?
>>
>>
>> Andrei
>
> Funny, I can reproduce up to 2.063.2, but not after that.

AFAIK I was the reason it was removed again. See my other post.

Am 15.04.2014 15:00, schrieb Benjamin Thaut:
> AFAIK I was the reason it was removed again. See my other post.

And herese the bug ticket: https://issues.dlang.org/show_bug.cgi?id=11244

On 4/15/14, 2:18 AM, bearophile wrote:
> The idea is to tell well apart the assignment of values (like scalars
> and fixed size arrays) from slice assignments. In general if you have a
> vector operation, use a []. There are corner cases (with arrays of
> arrays, fixed sized arrays of dynamic arrays, etc), that if you don't
> use such strict syntax, lead to undefined (ambiguous, weird) situations.
> The warning helps avoid that problem, and the warning will be replaced
> by a deprecation later.

This doesn't quite explain much. -- Andrei

Andrei Alexandrescu:

> This doesn't quite explain much. -- Andrei

Look at the issue:
https://issues.dlang.org/show_bug.cgi?id=7444

Bye,
bearophile

On Tue, 15 Apr 2014 11:47:24 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Andrei Alexandrescu:
>
>> This doesn't quite explain much. -- Andrei
>
> Look at the issue:
> https://issues.dlang.org/show_bug.cgi?id=7444

I agree with Andrei, and the rejection of the change.

On the left hand side, the [] operator is special *for arrays* in that it denotes you want to do an element-wise copy. On the right hand side, this is not the case, [] is simply an operator. It's a no-op if the rhs is an array, since [] just gets the array again.

Requiring it simply adds unneeded hoops through which you must jump, the left hand side denotes the operation, the right hand side does not, and in fact, this causes problems with types that overload [] to return an array (a very logical operation).

In particular, this would case issues with dcollections' ArrayList which returns a slice when doing []. The other example from Benjamin is essentially the same thing.

Note -- it would be nice (and more consistent IMO) if arr[] = range worked identically to arr[] = arr.

-Steve

On Tue, 15 Apr 2014 11:59:31 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On the left hand side, the [] operator is special *for arrays* in that it denotes you want to do an element-wise copy. On the right hand side, this is not the case, [] is simply an operator. It's a no-op if the rhs is an array, since [] just gets the array again.

Sorry, I had this wrong. The [] on the left hand side is actually part of the []= operator. But on the right hand side, it simply is a [] operator, not tied to the =. I erroneously thought the arr[] = ... syntax was special for arrays, but I forgot that it's simply another operator.

My opinion is still the same.

-Steve

On Tuesday, 15 April 2014 at 16:02:33 UTC, Steven Schveighoffer wrote:
> On Tue, 15 Apr 2014 11:59:31 -0400, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>> On the left hand side, the [] operator is special *for arrays* in that it denotes you want to do an element-wise copy. On the right hand side, this is not the case, [] is simply an operator. It's a no-op if the rhs is an array, since [] just gets the array again.
>
> Sorry, I had this wrong. The [] on the left hand side is actually part of the []= operator. But on the right hand side, it simply is a [] operator, not tied to the =. I erroneously thought the arr[] = ... syntax was special for arrays, but I forgot that it's simply another operator.
>
> My opinion is still the same.
>
> -Steve

Maybe we should require the []= operator to be written exactly like this.

t[] = v;

t.opSlice.opAssign(v) or t.opSliceAssign(v)? I bet most people (me included) will get this wrong 50% of the time.

Steven Schveighoffer:

> On the left hand side, the [] operator is special *for arrays* in that it denotes you want to do an element-wise copy. On the right hand side, this is not the case, [] is simply an operator. It's a no-op if the rhs is an array, since [] just gets the array again.
>
> Requiring it simply adds unneeded hoops through which you must jump,

What do you think are the reasons I suggested the enhancement for?

Bye,
bearophile

On Tue, 15 Apr 2014 13:46:11 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>
>> On the left hand side, the [] operator is special *for arrays* in that it denotes you want to do an element-wise copy. On the right hand side, this is not the case, [] is simply an operator. It's a no-op if the rhs is an array, since [] just gets the array again.
>>
>> Requiring it simply adds unneeded hoops through which you must jump,
>
> What do you think are the reasons I suggested the enhancement for?

To make people write code the way you like? :)

Honestly, it's like you require someone to call a function like:

T foo(T)(T t){return t;}

Just so you can see the foo there. I understand the idea, but the result is not logical, just superficial.

-Steve

On Tuesday, 15 April 2014 at 16:02:33 UTC, Steven Schveighoffer wrote:

> Sorry, I had this wrong. The [] on the left hand side is actually part of the []= operator. But on the right hand side, it simply is a [] operator, not tied to the =. I erroneously thought the arr[] = ... syntax was special for arrays, but I forgot that it's simply another operator.
>
> Steve, where do I find the []= operator in the documentation? It does not seem to be under Expressions like the other operators. Has it just not got there yet?
>
> Steve