April 16, 2014
On Tuesday, 15 April 2014 at 15:59:31 UTC, Steven Schveighoffer wrote:
> Requiring it simply adds unneeded hoops through which you must jump, the left hand side denotes the operation, the right hand side does not

Unfortunately, this particular operation is denoted by both sides.

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

Range or array, there are still two ways how it can work. The idea is to give the choice to programmer instead of the compiler.

> Sorry, I had this wrong. The [] on the left hand side is actually part of the []= operator.

There's no such operator. You can assign fixed-size array without slice syntax.
April 16, 2014
On Wednesday, 16 April 2014 at 06:59:30 UTC, Steve Teale wrote:
> 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

It's under op assignment operator overloading:
http://dlang.org/operatoroverloading.html#OpAssign
April 17, 2014
On Wed, 16 Apr 2014 02:59:29 -0400, Steve Teale <steve.teale@britseyeview.com> wrote:

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

dlang.org/operatoroverloading.html

Search for opSliceAssign

-Steve
April 17, 2014
On Wed, 16 Apr 2014 04:05:57 -0400, Kagamin <spam@here.lot> wrote:

> On Tuesday, 15 April 2014 at 15:59:31 UTC, Steven Schveighoffer wrote:
>> Requiring it simply adds unneeded hoops through which you must jump, the left hand side denotes the operation, the right hand side does not
>
> Unfortunately, this particular operation is denoted by both sides.

Not really. The = operator (opAssign) is different from the [] = operator (opSliceAssign).

I actually am ignorant of how this works under the hood for slices, what triggers element-wise copy vs. assign. But for custom types, this is how you would have to do it I think.

>> Note -- it would be nice (and more consistent IMO) if arr[] = range worked identically to arr[] = arr.
>
> Range or array, there are still two ways how it can work. The idea is to give the choice to programmer instead of the compiler.

But programmer cannot define new operators on slices.

>
>> Sorry, I had this wrong. The [] on the left hand side is actually part of the []= operator.
>
> There's no such operator. You can assign fixed-size array without slice syntax.

Fixed size array is a different type with different semantics from slices. You cannot assign the pointer/length of a fixed-size array, so opAssign devolves to opSliceAssign.

-Steve
April 17, 2014
On Thursday, 17 April 2014 at 12:38:24 UTC, Steven Schveighoffer wrote:
> I actually am ignorant of how this works under the hood for slices, what triggers element-wise copy vs. assign.

The compiler compiles whatever compiles. Currently only one mistake (type) is required to compile the wrong thing. With the fix it would require two mistakes (type and syntax), so the probability of mistake will be square of current probability. If the second mistake (syntax) is ruled out (template), the probability is zero.

>> Range or array, there are still two ways how it can work. The idea is to give the choice to programmer instead of the compiler.
>
> But programmer cannot define new operators on slices.

Cannot define new, but could choose from predefined ones.
April 29, 2014
Steven Schveighoffer:
> On Tue, 15 Apr 2014 13:46:11 -0400, bearophile
>> 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.

Issue 7444 allows to tell apart the two very different operations of this code, that look the same:


void main() {
    int[][3] x;
    int[]    y;
    int[]    z;

    x[] = z; // copies just the z pointer
    y[] = z; // copies the elements in z
}


In Phobos there are awkward names like walkLength, and in D we don't have a built-in "x in array" syntax, both just to tell apart the O(1) cases from the O(n) ones. Requiring the [] when you perform an array copy (instead of just a copy of the slice struct) allows to visually tell apart the O(1) operations from the O(n) ones:

void main() {
    int[][3] x;
    int[]    y;
    int[]    z;
    x[] = z;
    y[] = z[];
}



> the result is not logical, just superficial.

In D vector operations are allowed only with the [] syntax:

void main() {
    int[] a, b;
    a = a + b;       // Wrong
    a[] = a + b;     // Wrong
    a = a[] + b;     // Wrong
    a = a + b[];     // Wrong
    a[] = a[] + b;   // Wrong
    a = a[] + b[];   // Wrong
    a[] = a[] + b[]; // OK
}

A copy of the items can be seen as the simplest vector operation, so I think it's logical for it to require the [] like the others.

Bye,
bearophile
April 29, 2014
On Tue, 29 Apr 2014 14:08:59 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>> On Tue, 15 Apr 2014 13:46:11 -0400, bearophile
>>> 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.
>
> Issue 7444 allows to tell apart the two very different operations of this code, that look the same:
>
>
> void main() {
>      int[][3] x;
>      int[]    y;
>      int[]    z;
>
>      x[] = z; // copies just the z pointer
>      y[] = z; // copies the elements in z
> }

x[] = z[]; // copies just the z pointer
y[] = z[]; // copies the elements in z.

The problem is that the brackets don't affect the operation, just the type of the expression. To ascribe more logical meaning results in rather awkward and incorrect assumptions.

-Steve
April 29, 2014
On 4/29/14, 11:08 AM, bearophile wrote:
> In Phobos there are awkward names like walkLength

Love it. -- Andrie
April 29, 2014
On 4/29/14, 11:08 AM, bearophile wrote:
> In Phobos there are awkward names like walkLength

Love it. -- Andrei
April 29, 2014
Andrei Alexandrescu:

> On 4/29/14, 11:08 AM, bearophile wrote:
>> In Phobos there are awkward names like walkLength
>
> Love it. -- Andrei

The name like "walkLength" was chosen (by you?), instead of a more natural name like "length" (or even a nice, short, clean, readable, handy and easer to write name like "len" as in Python) to underline that walkLength could be O(n).

Bye,
bearophile