Re: What's the deal with "Warning: explicit element-wise assignment..."
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.)
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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?
Re: What's the deal with "Warning: explicit element-wise assignment..."
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…
Re: What's the deal with "Warning: explicit element-wise assignment..."
On 4/30/14, 6:18 AM, "Ola Fosheim Grøstad" " 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
Re: What's the deal with "Warning: explicit element-wise assignment..."
On 4/30/14, 5:58 AM, Andrej Mitrovic via Digitalmars-d wrote: On 4/30/14, Andrei Alexandrescu via Digitalmars-d 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
Re: What's the deal with "Warning: explicit element-wise assignment..."
On 4/30/14, 4:20 AM, "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). Making complexity an implementation detail is an antipattern. -- Andrei
Re: What's the deal with "Warning: explicit element-wise assignment..."
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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
On 4/30/14, Andrei Alexandrescu via Digitalmars-d 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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
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).
Re: What's the deal with "Warning: explicit element-wise assignment..."
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)
Re: What's the deal with "Warning: explicit element-wise assignment..."
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.)
Re: What's the deal with "Warning: explicit element-wise assignment..."
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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
On 4/29/14, 11:08 AM, bearophile wrote: In Phobos there are awkward names like walkLength Love it. -- Andrie
Re: What's the deal with "Warning: explicit element-wise assignment..."
On 4/29/14, 11:08 AM, bearophile wrote: In Phobos there are awkward names like walkLength Love it. -- Andrei
Re: What's the deal with "Warning: explicit element-wise assignment..."
On Tue, 29 Apr 2014 14:08:59 -0400, bearophile 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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
On Wed, 16 Apr 2014 04:05:57 -0400, Kagamin 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
Re: What's the deal with "Warning: explicit element-wise assignment..."
On Wed, 16 Apr 2014 02:59:29 -0400, 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? dlang.org/operatoroverloading.html Search for opSliceAssign -Steve
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
On Tue, 15 Apr 2014 13:46:11 -0400, bearophile 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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
On Tuesday, 15 April 2014 at 16:02:33 UTC, Steven Schveighoffer wrote: On Tue, 15 Apr 2014 11:59:31 -0400, Steven Schveighoffer 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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
On Tue, 15 Apr 2014 11:59:31 -0400, Steven Schveighoffer 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
Re: What's the deal with "Warning: explicit element-wise assignment..."
On Tue, 15 Apr 2014 11:47:24 -0400, bearophile 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
Re: What's the deal with "Warning: explicit element-wise assignment..."
Andrei Alexandrescu: This doesn't quite explain much. -- Andrei Look at the issue: https://issues.dlang.org/show_bug.cgi?id=7444 Bye, bearophile
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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 is better than where and 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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
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[][] }
Re: What's the deal with "Warning: explicit element-wise assignment..."
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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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 is better than where and 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 ;)
Re: What's the deal with "Warning: explicit element-wise assignment..."
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 is better than where and 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[]; }
Re: What's the deal with "Warning: explicit element-wise assignment..."
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 is better than where and 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.
Re: What's the deal with "Warning: explicit element-wise assignment..."
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 is better than where and 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[];
Re: What's the deal with "Warning: explicit element-wise assignment..."
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
Re: What's the deal with "Warning: explicit element-wise assignment..."
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 is better than where and 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.