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
parent reply "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
parent reply "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
next sibling parent reply "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
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 reply "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
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.


 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
Apr 16 2014
prev 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.


 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
Apr 17 2014
prev sibling parent reply "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
parent reply "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
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 parent reply "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
parent reply "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
parent reply "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
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 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 reply "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
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 "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 parent reply 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
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 parent reply "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
parent reply "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
next sibling parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply 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
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 parent reply 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
parent reply "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
parent reply "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
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
prev sibling next sibling parent reply "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
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 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
next sibling parent reply "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
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 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 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