www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the deal with "Warning: explicit element-wise assignment..."

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 14 2014
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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

The correct syntax is writeAvail_[0 .. buf.length] = buf[]; as the other syntax is for assigning a single value to all elements of the destination array. At least that's how I've always seen it. I'm not sure what that warning is talking about though.
Apr 15 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 We've just enabled warnings as errors in our build system at 
 work and suddenly:

It's much better to enable warnings since day -1, that means the day before you start creating your D project. That's why I'd like D compilers to have warnings active on default and to have a switch to disable them on request (Walter has not yet answered about this idea).
 What's the idea?

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. Bye, bearophile
Apr 15 2014
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 15.04.2014 11:18, schrieb bearophile:
 Andrei Alexandrescu:

 We've just enabled warnings as errors in our build system at work and
 suddenly:

It's much better to enable warnings since day -1, that means the day before you start creating your D project. That's why I'd like D compilers to have warnings active on default and to have a switch to disable them on request (Walter has not yet answered about this idea).
 What's the idea?

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. Bye, bearophile

It was a error once, but many situations were not detected correctly. So I hope before it becomes deprecated, it should first be properly working. One example for a situation that did not work correctly: struct MyArray { int[] opSlice() { ... } } void someFunc() { MyArray a; int[] b; b[] = a[]; // <- problem here. compiler wants you to write b[] = a[][] }
Apr 15 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 15 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/29/14, 11:08 AM, bearophile wrote:
 In Phobos there are awkward names like walkLength

Love it. -- Andrie
Apr 29 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/29/14, 11:08 AM, bearophile wrote:
 In Phobos there are awkward names like walkLength

Love it. -- Andrei
Apr 29 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/29/14, 4:09 PM, bearophile wrote:
 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).

"length" was already taken, and it seemed unbecoming to have "len" describe the longer operation. I find "walkLength" awesomely suggestive. -- Andrei
Apr 29 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/14, 5:58 AM, Andrej Mitrovic via Digitalmars-d wrote:
 On 4/30/14, Andrei Alexandrescu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 4/29/14, 11:08 AM, bearophile wrote:
 In Phobos there are awkward names like walkLength

Love it. -- Andrei

std.algorithm.count also works with any input range, they can use that if they don't like walkLength. Unless it has some limitations? I can't think of any.

Yah, they overlap in functionality but only somewhat. walkLength is O(1) on ranges with length, and it allows a convenient "up to" parameter. Andrei
Apr 30 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/14, 4:20 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote:
 walkLength is a really good name. Clear, concise, to the point. It's
 not often that you can make such a short name that explains the
 behaviour so well.

Actually it isn't a good abstraction as it exposes implementation internals. The name should indicate what you get (the calculating of a result), not how the framework obtains it (sequential scan).

Making complexity an implementation detail is an antipattern. -- Andrei
Apr 30 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/30/14, 6:18 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:
 On Wednesday, 30 April 2014 at 11:52:14 UTC, Dicebot wrote:
 And that would have been quite a close guess actually as walkLength is
 constrained to accept only finite InputRanges :) "walk" here implies
 iteration and iteration implies O(n).

The common term is "count", "countNodes", "countElements" etc... Why all the specialized functions in algorithm.d? Why not just have a default predicate that is always true and do compile time optimizations?

That would be an awful idea. -- Andrei
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
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

It is mostly a style warning but greatly helps to reduce reading ambiguity: // "assign rvalue to lvalue element-wise" // OR // "assign rvalue to all members of lvalue" // need to know rvalue type to be sure lvalue[] = rvalue; // clear and simple lvalue[] = rvalue[];
Apr 15 2014
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
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.
Apr 15 2014
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
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.
Apr 15 2014
parent Benjamin Thaut <code benjamin-thaut.de> writes:
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
Apr 15 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 15 April 2014 at 10:38:06 UTC, Dicebot wrote:
 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

It is mostly a style warning but greatly helps to reduce reading ambiguity: // "assign rvalue to lvalue element-wise" // OR // "assign rvalue to all members of lvalue" // need to know rvalue type to be sure lvalue[] = rvalue; // clear and simple lvalue[] = rvalue[];

Too bad the warning doesn't work both ways, when using a "gratuitous" []: void main() { int[][] a = [[], [], []]; int[] b = [1, 2]; //"assign rvalue to lvalue element-by-element" ? a[] = b[]; }
Apr 15 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 15 April 2014 at 11:23:30 UTC, monarch_dodra wrote:
 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.

I think it was removed because detection implementation was not mature enough and resulted in confusing behavior for corner cases. You have already already spotted one ;)
Apr 15 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:

 Funny, I can reproduce up to 2.063.2, but not after that.

I think it was removed because detection implementation was not mature enough and resulted in confusing behavior for corner cases. You have already already spotted one ;)

So much work to put that warning in... -.- Bye, bearophile
Apr 15 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 15 April 2014 at 11:27:41 UTC, Dicebot wrote:
 On Tuesday, 15 April 2014 at 11:23:30 UTC, monarch_dodra wrote:
 Funny, I can reproduce up to 2.063.2, but not after that.

I think it was removed because detection implementation was not mature enough and resulted in confusing behavior for corner cases. You have already already spotted one ;)

Well, I merely found something that is ambiguous to begin with, but didn't trigger a warning. It's not an actual false positive.
Apr 15 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 This doesn't quite explain much. -- Andrei

Look at the issue: https://issues.dlang.org/show_bug.cgi?id=7444 Bye, bearophile
Apr 15 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 15 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 15 2014
prev sibling next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
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.
Apr 15 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Apr 15 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 15 2014
prev sibling next sibling parent "Steve Teale" <steve.teale britseyeview.com> writes:
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

Apr 15 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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.
Apr 16 2014
prev sibling next sibling parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
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.

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
Apr 16 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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.

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
Apr 17 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 17 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
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.
Apr 17 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Apr 29 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 29 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Apr 29 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 29 April 2014 at 23:09:42 UTC, bearophile wrote:
 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).

I usually prefix such cases with "calc", e.g. calcLength / calc_length
Apr 29 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 29 April 2014 at 18:09:00 UTC, bearophile wrote:
 In Phobos there are awkward names like walkLength

walkLength is a really good name. Clear, concise, to the point. It's not often that you can make such a short name that explains the behaviour so well.
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote:
 walkLength is a really good name. Clear, concise, to the point. 
 It's not often that you can make such a short name that 
 explains the behaviour so well.

Actually it isn't a good abstraction as it exposes implementation internals. The name should indicate what you get (the calculating of a result), not how the framework obtains it (sequential scan). "walk" indicates that you can use a visitor-pattern, thus it is a misleading name. (Not that it matters.)
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 11:20:40 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote:
 walkLength is a really good name. Clear, concise, to the 
 point. It's not often that you can make such a short name that 
 explains the behaviour so well.

Actually it isn't a good abstraction as it exposes implementation internals. The name should indicate what you get (the calculating of a result), not how the framework obtains it (sequential scan). "walk" indicates that you can use a visitor-pattern, thus it is a misleading name. (Not that it matters.)

For algorithms execution complexity is not a mere implementation detail. "walk' implies exactly that it is O(n) as opposed to O(1) of built-in length properties. It is a wise approach.
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 11:24:09 UTC, Dicebot wrote:
 For algorithms execution complexity is not a mere 
 implementation detail. "walk' implies exactly that it is O(n) 
 as opposed to O(1) of built-in length properties. It is a wise 
 approach.

For you maybe. For me the response is "walkLength???" WTF is that? Does this imply a length restricted forEach? I've never seen "walk" or "traverse" being used for indicating O(n), it is usually used to indicate something you can utilize in order to traverse a data-structure. That's how the terms are used in CS. "Walk" is an imperative. "walk length" indicates "walk the length of", not "calculate the length of". But naming functions is often more difficult than writing the code. (not a joke)
Apr 30 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 30 April 2014 at 11:35:56 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 30 April 2014 at 11:24:09 UTC, Dicebot wrote:
 For algorithms execution complexity is not a mere 
 implementation detail. "walk' implies exactly that it is O(n) 
 as opposed to O(1) of built-in length properties. It is a wise 
 approach.

For you maybe. For me the response is "walkLength???" WTF is that? Does this imply a length restricted forEach?

And that would have been quite a close guess actually as walkLength is constrained to accept only finite InputRanges :) "walk" here implies iteration and iteration implies O(n).
Apr 30 2014
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4/30/14, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 4/29/14, 11:08 AM, bearophile wrote:
 In Phobos there are awkward names like walkLength

Love it. -- Andrei

std.algorithm.count also works with any input range, they can use that if they don't like walkLength. Unless it has some limitations? I can't think of any.
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 11:52:14 UTC, Dicebot wrote:
 And that would have been quite a close guess actually as 
 walkLength is constrained to accept only finite InputRanges :) 
 "walk" here implies iteration and iteration implies O(n).

The common term is "count", "countNodes", "countElements" etc... Why all the specialized functions in algorithm.d? Why not just have a default predicate that is always true and do compile time optimizations? I find fragmented libraries hard to use.
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 15:51:09 UTC, Andrei Alexandrescu 
wrote:
 Why all
 the specialized functions in algorithm.d? Why not just have a 
 default
 predicate that is always true and do compile time 
 optimizations?

That would be an awful idea. -- Andrei

Why? By having a gazillion functions doing almost the same thing you are moving away from generic programming…
Apr 30 2014
prev sibling next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 15:45:32 UTC, Andrei Alexandrescu 
wrote:
 The name should indicate what you get (the calculating of a 
 result), not
 how the framework obtains it (sequential scan).

Making complexity an implementation detail is an antipattern. -- Andrei

Where did I say that?
Apr 30 2014
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 30 April 2014 at 16:48:50 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 30 April 2014 at 15:45:32 UTC, Andrei 
 Alexandrescu wrote:
 The name should indicate what you get (the calculating of a 
 result), not
 how the framework obtains it (sequential scan).

Making complexity an implementation detail is an antipattern. -- Andrei

Where did I say that?

I think the thrust of the statement is this: by shoving under the rug the method by which the length is obtained, it also conceals the algorithmic complexity and hinders good judgement on what tradeoffs are being made. I can see the argument for either position, really. Personally, I think "calculate" sufficiently denotes that there's nontrivial work going into the process, but "walk" makes it fairly clear that O(n) should be expected. It's an awkward discussion because neither is very discoverable in the first place; maybe make one an alias for the other and give people a sporting chance to find the damn thing? -Wyatt
Apr 30 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 30 April 2014 at 19:55:08 UTC, Wyatt wrote:
 It's an awkward discussion because neither is very discoverable 
 in the first place; maybe make one an alias for the other and 
 give people a sporting chance to find the damn thing?

With an IDE discoverable probably means that it follows the conventions of the language for the first phrase. I.e. it should start with "length" so that it pops up when you start typing "len…". Well, if it is callable with dot-notation. I know from experience that I avoid using functions that I don't remember the name of. That is one reason I use list comprehensions so much in Python. The more dedicated functions takes time to look up. I think large sections of Python's standard library could be wiped out in favour of the more powerful abstractions and mechanisms it has now. And even if a very narrow function might be faster, I probably will write my own loop if speed is that important. So I would favour fewer and more generic functions, with better optimization. (I think you can get a long way by just using templates, but others have suggested AST macros, and pattern/matching term rewriting is also a possibility.)
Apr 30 2014