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 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 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: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: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 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.
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, 4:20 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@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
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 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
Re: What's the deal with Warning: explicit element-wise assignment...
On 4/30/14, 6:18 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@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
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 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 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 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...
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 Tue, 29 Apr 2014 14:08:59 -0400, bearophile bearophileh...@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
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 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...
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, 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...
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 Wed, 16 Apr 2014 02:59:29 -0400, Steve Teale steve.te...@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
Re: What's the deal with Warning: explicit element-wise assignment...
On Wed, 16 Apr 2014 04:05:57 -0400, Kagamin s...@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
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 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 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 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 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.
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 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[];
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 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.
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 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[];
}
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 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 ;)
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: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...
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...
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.
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...
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...
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 Tue, 15 Apr 2014 11:47:24 -0400, bearophile bearophileh...@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
Re: What's the deal with Warning: explicit element-wise assignment...
On Tue, 15 Apr 2014 11:59:31 -0400, Steven Schveighoffer schvei...@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
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 schvei...@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.
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 Tue, 15 Apr 2014 13:46:11 -0400, bearophile bearophileh...@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
