http://d.puremagic.com/issues/show_bug.cgi?id=3971


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch


--- Comment #20 from timon.gehr@gmx.ch 2011-11-19 12:32:29 PST ---
Also from that thread:

First thing:

int[3] a=3; // kill it!!

Rest:

a[] is _just a shortcut_ for a[0..$]! Are you really suggesting to disallow slicing?


You are thinking too much in terms of syntax and not enough in terms of semantics.

They are basically two distinct things involved here:

1. static arrays and lvalue slices
2. dynamic arrays and rvalue slices

1 implies value semantics, 2 implies reference semantics, where value semantics overrides reference semantics.

Any other distinction is more or less arbitrary. As you pointed out, the main indicator of distinction is value vs reference semantics of the performed assignments.

We certainly agree on this:

Rhs is an array, is it compilable?
a       / b             a=b     a[]=b   a=b[]   a[]=b[]
int[3u] / int[3u]       ?       ?       ?       true
int[3u] / int[]         ?       ?       ?       true
int[]   / int[3u]       ?       ?       ?       true
int[]   / int[]         ?       ?       ?       true


Now, a dynamic array a is equivalent to a[], and a static array b is equivalent to an lvalue slice b[]=.

This gives the following equivalence classes of operations:

Rhs is an array, is it compilable?
a       / b             a=b     a[]=b   a=b[]   a[]=b[]
int[3u] / int[3u]       1       1       2       2
int[3u] / int[]         2       2       2       2
int[]   / int[3u]       3       1       4       2
int[]   / int[]         4       2       4       2

Any of the same class should behave the same.

Now, you suggest in both proposals to allow at least one of class 2 and at least one of class 4. Filling all those out delivers:

Rhs is an array, is it compilable?
a       / b             a=b     a[]=b   a=b[]   a[]=b[]
int[3u] / int[3u]       (1)     (1)     true    true
int[3u] / int[]         true    true    true    true
int[]   / int[3u]       (3)     (1)     true    true
int[]   / int[]         true    true    true    true

1 is "assign value to value". 3. is "assign value to reference".

The upper left corner should certainly be true, values of any mutable type should be able to be assigned to themselves.


This leaves:

Rhs is an array, is it compilable?
a       / b             a=b     a[]=b   a=b[]   a[]=b[]
int[3u] / int[3u]       true    true    true    true
int[3u] / int[]         true    true    true    true
int[]   / int[3u]       (3)     true    true    true
int[]   / int[]         true    true    true    true


3 is the odd thing out. Now let's think about it, what should:

int[] a;
int[3] b;

a=b;

do?

The answer is, there are two options.

1. implicitly slice b
2. copy b by value into a

One is as arbitrary as the other, so it should be disallowed in a sane design. Which leaves:

Rhs is an array, is it compilable?
a       / b             a=b     a[]=b   a=b[]   a[]=b[]
int[3u] / int[3u]       true    true    true    true
int[3u] / int[]         true    true    true    true
int[]   / int[3u]       FALSE   true    true    true
int[]   / int[]         true    true    true    true

Rhs is a element, is it compilable?
a                       a=N     a[]=N   a[0..2]=N
int[3u]                 FALSE   true    true
int[]                   false   true    true


And that is how it should be.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971



--- Comment #21 from Don <clugdbug@yahoo.com.au> 2011-11-19 13:52:04 PST ---
(In reply to comment #20)
> Also from that thread:
> 
> First thing:
> 
> int[3] a=3; // kill it!!
> 
> Rest:
> 
> a[] is _just a shortcut_ for a[0..$]! Are you really suggesting to disallow slicing?

Currently it is just a shortcut, but that's a horrible waste of a symbol. [] is
a potentially very useful piece of syntax, which is currently almost unused.
It is currently used to resolve ambiguity in array operations. In all other
cases, it's redundant.
Bearophile has seen how successful it is in array operations, and would like to
see it used in the same way in simple element-wise assignment.

That is, element wise assignment should never occur without a slice syntax.

(The converse isn't true, block assignment sometimes occurs even when slices
are present, see below).

The analysis avoids the confusing case: where the element type is an array.

int [][3] x;
int [] y;
int [] z;

x[] = z;
y[] = z;
These look the same, but do very different things. The first one just copies
the z pointer. The second one copies the elements in z.
y[] = z[]; makes things clearer.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971



--- Comment #22 from bearophile_hugs@eml.cc 2011-11-25 16:54:31 PST ---
In DMD 2.057head this code fails still:


void main() {
    int[3] a = [1, 2, 3];
    int[3] b = [10, 20, 30];
    auto c[] = a[] + b[]; // no identifier for declarator c[]
}



void main() pure nothrow {
    int[3] a = [1, 2, 2];
    int[3] b = [10, 20, 20];
    const c = a[] + b[]; // Error: Array operation a[] + b[] not implemented
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com


--- Comment #23 from yebblies <yebblies@gmail.com> 2012-02-03 18:46:19 EST ---
(In reply to comment #22)
> In DMD 2.057head this code fails still:
> 
> 
> void main() {
>     int[3] a = [1, 2, 3];
>     int[3] b = [10, 20, 30];
>     auto c[] = a[] + b[]; // no identifier for declarator c[]
> }
> 
> 
> 
> void main() pure nothrow {
>     int[3] a = [1, 2, 2];
>     int[3] b = [10, 20, 20];
>     const c = a[] + b[]; // Error: Array operation a[] + b[] not implemented
> }

This is a different bug.  Are all the other cases fixed?

I know this is an old report, but the way cases are presented in the initial report make it a pain to test.  The cases I've quoted above are much better.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971



--- Comment #24 from bearophile_hugs@eml.cc 2012-02-05 05:52:16 PST ---
(In reply to comment #23)

> Are all the other cases fixed?
> 
> I know this is an old report, but the way cases are presented in the initial report make it a pain to test.  The cases I've quoted above are much better.

I think that eventually this messy bug report will need to be closed, to be replaced by a new clean bug report :-)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971



--- Comment #25 from yebblies <yebblies@gmail.com> 2012-02-06 00:55:42 EST ---
Eventually?  Why not now?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971



--- Comment #26 from bearophile_hugs@eml.cc 2012-02-05 07:25:01 PST ---
(In reply to comment #25)
> Eventually?  Why not now?

Before closing this bug, a new issue needs to be written and opened, of course.

And I can't want to write a new issue until people give me good answers about what the right behaviors are.

See this thread where I have asked questions and shown two alternative proposals:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=149289


I'd like this code to be refused at compile-time:


void main() {
    int[3] a;
    a = 1;
    assert(a == [1, 1, 1]);
}



Just as this is not accepted:

void main() {
    int[] b = new int[3];
    b = 1;
    assert(b == [1, 1, 1]); //Error: cannot implicitly convert expression (1)
of type int to int[]
}



And to be required:

void main() {
    int[3] a;
    a[] = 1;
    assert(a == [1, 1, 1]);
}


I'd like the [] to be required every time an O(n) vector operation is done,
for:
- constancy with all other vector operations among two arrays, that require [];
- and to avoid unwanted (and not easy to spot in the code) O(n) operations;
- bugs and confusion in D newbies that don't have memorized all current special
cases.


But there are other less clear-cut situations. If O(n) vector ops require a [],
then this too has to be a compile-time error (despite a and b are values):


void main() {
    int[3] a, b;
    a = b; // Not OK, hidden vector op
}


(Struct copies are O(n) operations, but their size if known at compile-time.)


While this code is OK:

void main() {
    int[] a = new int[3];
    int[] b = new int[3];
    a = b; // OK, copies just an array fat reference
}



Maybe two cases with dynamic arrays are better as compile-time syntax errors to keep more symmetry, I am not sure:

void main() {
    int[] a = new int[3];
    int[] b = new int[3];
    a[] = b; // error
    a = b[]; // error
}


It's not a good idea to open a new bug report before such questions have a good answer because the new bug report risks to quickly become almost as messy as this old one.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971



--- Comment #27 from timon.gehr@gmx.ch 2012-02-05 07:42:38 PST ---
Every O(n) vector operation already requires [].

> But there are other less clear-cut situations. If O(n) vector ops require a [],
> then this too has to be a compile-time error (despite a and b are values):
>
>
> void main() {
>    int[3] a, b;
>    a = b; // Not OK, hidden vector op
> }

The "hidden" operation is O(1).

If what you want is differing behavior based on whether an operation is O(n) or
O(1), the language already does what you want.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971



--- Comment #28 from yebblies <yebblies@gmail.com> 2012-02-06 02:56:56 EST ---
The problem with this bug report is that there are too many different issues. Most of those cases you just mentioned deserve their own bug report, and to be evaluated individually.  Large and unclear bug reports are much harder to process than concise ones targeting a single issue.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=3971


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #30 from bearophile_hugs@eml.cc 2012-02-05 11:14:19 PST ---
I close this issue, I have split this into issue 7444 and issue 7445

If you see something missing inside those two reports, then please add the missing stuff there or in a new bug report.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------