This makes perfect sense to me as a new-comer, and having not had much experience writing this sort of code, this is exactly how I would have assumed it is now.<div>I would have been in for a confusing surprise had I tried to do any of this stuff.<br>
<br><div class="gmail_quote">On 16 November 2011 05:24, bearophile <span dir="ltr"><<a href="mailto:bearophileHUGS@lycos.com" target="_blank">bearophileHUGS@lycos.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The Bugzilla issues that I really care about is a not an useless long list, it's about fifteen items long, and this post is about one of them.<br>
<br>
I think current array slice assign syntax is a bit messy, and I think this should be addressed.<br>
<br>
Kenji Hara has recently written a very nice program (that here I have modified a bit for clarity) that shows the current array assign situation:<br>
<br>
<br>
import std.stdio, std.typetuple;<br>
<br>
void main() {<br>
writeln("Rhs is an array, is it compilable?");<br>
writeln("a\t/ b\t\ta=b\ta[]=b\ta=b[]\ta[]=b[]");<br>
<br>
foreach (i, Lhs; TypeTuple!(int[3], int[]))<br>
foreach (j, Rhs; TypeTuple!(int[3], int[])) {<br>
writef("%s\t/ %s ", Lhs.stringof, Rhs.stringof);<br>
Lhs a = [0,0,0];<br>
Rhs b = [1,2,3];<br>
writef("\t%s", __traits(compiles, { a = b; }));<br>
writef("\t%s", __traits(compiles, { a[] = b; }));<br>
writef("\t%s", __traits(compiles, { a = b[]; }));<br>
writef("\t%s", __traits(compiles, { a[] = b[]; }));<br>
writeln();<br>
}<br>
<br>
<br>
writeln("\nRhs is a element, is it compilable?");<br>
writeln("a\t\t\ta=N\ta[]=N\ta[0..2]=N");<br>
<br>
foreach (Lhs; TypeTuple!(int[3], int[])) {<br>
writef("%s\t\t", Lhs.stringof);<br>
Lhs a = [0,0,0];<br>
writef("\t%s", __traits(compiles, { a = 9; }));<br>
writef("\t%s", __traits(compiles, { a[] = 9; }));<br>
writef("\t%s", __traits(compiles, { a[0..2] = 9; }));<br>
writeln();<br>
}<br>
}<br>
<br>
<br>
<br>
Currently (DMD 2.057head, despite I think Walter has not updated DMD version number yet) it prints:<br>
<br>
<br>
Rhs is an array, is it compilable?<br>
a / b a=b a[]=b a=b[] a[]=b[]<br>
int[3u] / int[3u] true true true true<br>
int[3u] / int[] true true true true<br>
int[] / int[3u] true true true true<br>
int[] / int[] true true true true<br>
<br>
Rhs is a element, is it compilable?<br>
a a=N a[]=N a[0..2]=N<br>
int[3u] true true true<br>
int[] false true true<br>
<br>
<br>
<br>
This also means this is currently accepted:<br>
<br>
void main() {<br>
int[3] a;<br>
a = 1;<br>
assert(a == [1, 1, 1]);<br>
}<br>
<br>
<br>
While this is not accepted:<br>
<br>
void main() {<br>
int[] b = new int[3];<br>
b = 1;<br>
assert(b == [1, 1, 1]); //Error: cannot implicitly convert expression (1) of type int to int[]<br>
}<br>
<br>
<br>
<br>
I'd like D to require a[]=1 in that first case too.<br>
<br>
I'd like the [] to be required every time an O(n) vector operation is done, for:<br>
- constancy with all other vector operations among two arrays, that require [];<br>
- and to avoid unwanted (and not easy to spot in the code) O(n) operations;<br>
- bugs and confusion in D newbies that don't have memorized all current special cases.<br>
<br>
On the other hand Don says that [] is only required for lvalues.<br>
<br>
I think this boils to a new table like this:<br>
<br>
<br>
Rhs is an array, is it compilable?<br>
a / b a=b a[]=b a=b[] a[]=b[]<br>
int[3u] / int[3u] FALSE true FALSE true<br>
int[3u] / int[] FALSE true FALSE true<br>
int[] / int[3u] FALSE true FALSE true<br>
int[] / int[] true true true true<br>
<br>
Rhs is a element, is it compilable?<br>
a a=N a[]=N a[0..2]=N<br>
int[3u] FALSE true true<br>
int[] false true true<br>
<br>
<br>
Now if there's a [] on the left, then it's an O(n) vector operation (like a copy), otherwise it's O(1).<br>
<br>
That also means:<br>
<br>
void main() {<br>
int[] a = new int[3];<br>
int[] b = new int[3];<br>
a = b; // OK, copies just array fat reference<br>
}<br>
<br>
void main() {<br>
int[3] a, b;<br>
a = b; // Not OK, hidden vector op<br>
}<br>
<br>
<br>
I am not sure this new table is fully correct, but it's a start. Fixes of mistakes are welcomes.<br>
<br>
-----------------------<br>
<br>
This is an alternative proposal.<br>
<br>
On the other hand this vector op syntax doesn't currently compile:<br>
<br>
void main() {<br>
int[3] a, b;<br>
a[] += b;<br>
}<br>
<br>
<br>
So if array assign is seen as a normal vector op, then the [] is needed on the right too:<br>
<br>
<br>
Rhs is an array, is it compilable?<br>
a / b a=b a[]=b a=b[] a[]=b[]<br>
int[3u] / int[3u] FALSE FALSE FALSE true<br>
int[3u] / int[] FALSE FALSE FALSE true<br>
int[] / int[3u] FALSE FALSE FALSE true<br>
int[] / int[] true FALSE FALSE true<br>
<br>
Rhs is a element, is it compilable?<br>
a a=N a[]=N a[0..2]=N<br>
int[3u] FALSE true true<br>
int[] false true true<br>
<br>
<br>
Where the two cases with dynamic arrays are syntax errors to keep more symmetry:<br>
<br>
void main() {<br>
int[] a = new int[3];<br>
int[] b = new int[3];<br>
a[] = b; // error<br>
a = b[]; // error<br>
}<br>
<br>
-----------------------<br>
<br>
Lot of time ago I have opened bug issue 3971 on this topic, but that Bugzilla thread contains various mistakes and some parts of it are obsolete.<br>
<br>
Bye,<br>
<span><font color="#888888">bearophile<br>
</font></span></blockquote></div><br>
</div>