www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3971] New: Syntax & semantics for array assigns

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971

           Summary: Syntax & semantics for array assigns
           Product: D
           Version: 2.041
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



This is written in the page about arrays:
http://www.digitalmars.com/d/2.0/arrays.html

s[] = t;      // the 3 elements of t[3] are copied into s[3]
s[] = t[];    // the 3 elements of t[3] are copied into s[3]
s[] = 3;      // same as s[0] = 3, s[1] = 3, s[2] = 3
p[0..2] = 3;  // same as p[0] = 3, p[1] = 3


It's not good to have two different syntaxes to do the same thing, or two
similar syntaxes with a different computational complexity.

So I suggest to modify the array assign syntax this way:


a[] = b[];  static  dynamic
static      OK1     OK1
dynamic     OK1     OK1

a = b[];    static  dynamic
static      Err     Err
dynamic     Err     Err

a[] = b;    static  dynamic
static      Err     Err
dynamic     Err     Err

a = b;      static  dynamic
static      Err2    Err
dynamic     Err     OK2

int i; a=i; static  dynamic
            Err     Err

int i;
a[] = i;    static  dynamic
            OK3     OK3

Key:
  Err =  Syntax error
  OK1 =  Copies all items from an array to the oter.
  OK2 =  Copies just the stuct of the dynamic array, array body not copied.
  OK3 =  Copies the value to all the items of the array.
  Err2 = Syntax error, becase there is no reference to copy, better to keep
tidy the language.


You can see that this too is disallowed:
int a, b;
a = b;

This breaks generic code, but it's not good when the same syntax can be O(1)
(because the same syntax used on dynamic arrays is a O(1)) or O(n), and the too
is different.

If you have comments please add them.

I like that matrix because it contains all cases, so it's easy to see and
design the situation, even if you don't agree with its contents.

The accepted final version of that matrix can even be added back to the arrays
page.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Mar 15 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




But be careful, in this code Tri c[] is seen as Tri[] c, and it doesn't
compile:

alias double[3] Tri;
void main() {
    Tri a = [1, 2, 3];
    Tri b = [10, 20, 30];
    Tri c[] = a1[] - b1[]; // ERR
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 12 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




11:07:25 PDT ---
What "static", "dynamic", "a" and "b" mean? And those diagrams?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 14 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




"a" and "b" are arrays.

"dynamic" means dynamic array.

"static" means stack-allocated fixed-sized array.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 14 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




13:08:07 PDT ---
a = b;      static  dynamic
static      Err2    Err
dynamic     Err     OK2
^ As I understand, this disallows assignment of a static array to the dynamic
one?

Is this related to bug 3395?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 16 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




This:
a = b;      static  dynamic
static      Err2    Err
dynamic     Err     OK2

Means:
int[5] a, b;
a = b; // Err2
int[] c = new int[5];
a = c; // Err
c = a; // Err
int[] d = new int[5];
c = d; // OK

But:
a[] = c[]; // OK
c[] = a[]; // OK

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 18 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




14:11:17 PDT ---
Why c=a; is an error?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




You are right, the c=a; case can be allowed, it can just copy the ptr and
length of the static array inside the struct of the dynamic array (this is how
D currently works). Thank you for spotting it.

All this discussion looks academic because so far Walter seems uninterested in
this enhancement request.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au





 All this discussion looks academic because so far Walter seems uninterested in
 this enhancement request.


Bearophile, please stop making absurd statements like that one. If Walter makes
no comment on something, you can't conclude *anything* about his attitude to
it. He's just extremely busy.
---

Almost all bugs and weird behaviour involving array operations happen because
internally the compiler doesn't distinguish between  x[] and x, where x is a
dynamic array. This causes a multitude of problems, especially when
multidimensional arrays are involved.

I agree with you that this syntax is problematic. I don't understand why it's
currently permitted:

int[3] s;
int[3] t;
s[] = t;      // the 3 elements of t[3] are copied into s[3]

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 19 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




08:14:28 PDT ---

 internally the compiler doesn't distinguish between  x[] and x, where x is a
 dynamic array.


This means, that array ops are a huge hack?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971






 internally the compiler doesn't distinguish between  x[] and x, where x is a
 dynamic array.


 This means, that array ops are a huge hack?


No. According to the spec, it's not supposed to. x[] is exactly the same as x.
The [] is only required for lvalues. So
int [4] a, b, c;
a[] =  b + c; // should work
It's almost as if there's a []= operator.
At the moment, though, a[] = b+c; fails, and you need to write a[] = b[]+c[].

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




09:24:59 PDT ---
Such behavior is very bug-prone: in the case of tag array it does matter
whether you meant array op or array itself as value, see bug 3395 comment 2. If
compiler can distinguish between x and x[] it can raise error, but judging from
what you tell, compiler tries to assume.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 04 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971






 Such behavior is very bug-prone: in the case of tag array it does matter
 whether you meant array op or array itself as value, see bug 3395 comment 2. If
 compiler can distinguish between x and x[] it can raise error, but judging from
 what you tell, compiler tries to assume.


Walter has just clarified this in the newsgroup: it is intended to be mandatory
to use [] inside array expressions. I have made a patch which enforces this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 04 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




While compiling this program:

void main() {
    int[1] a1;
    int[1] a2[] = a1[];
}


compatibility with C syntax produces this error message:
test.d(3): Error: cannot implicitly convert expression (a1[]) of type int[] to
int[1u][]

See also bug 4580 as a way to solve this problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 11 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |major



This is not an enhancement any more, because Walter has accepted something like
this.
Also, raising its priority a little because there is a risk of this bug
becoming permanent in D2 code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 28 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971


Denis Derman <denis.spir gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |denis.spir gmail.com



PST ---


 You are right, the c=a; case can be allowed, it can just copy the ptr and
 length of the static array inside the struct of the dynamic array (this is how
 D currently works). Thank you for spotting it.


Is it really the way D currently works? Doesn't it dup the static array
instead? I thought static ones were on the stack while dynamic ones were on the
heap.

Denis

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 06 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com





 a[] = b[];  static  dynamic
 static      OK1     OK1
 dynamic     OK1     OK1
 
 a = b[];    static  dynamic
 static      Err     Err
 dynamic     Err     Err
 
 a[] = b;    static  dynamic
 static      Err     Err
 dynamic     Err     Err
 
 a = b;      static  dynamic
 static      Err2    Err
 dynamic     Err     OK2


I'm not sure I like this.  What, exactly, would be the semantic difference
between the rvalue b and the rvalue b[]?  Currently, they are the same, and
changing this might be confusing.


 int i; a=i; static  dynamic
             Err     Err
 
 int i;
 a[] = i;    static  dynamic
             OK3     OK3


This is how D behaves currently.


 Key:
   Err =  Syntax error
   OK1 =  Copies all items from an array to the oter.
   OK2 =  Copies just the stuct of the dynamic array, array body not copied.
   OK3 =  Copies the value to all the items of the array.
   Err2 = Syntax error, becase there is no reference to copy, better to keep
 tidy the language.


Making it a _syntax_ error cannot be done, because D's grammar is context-free
by design.


 
 You can see that this too is disallowed:
 int a, b;
 a = b;


???

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 06 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




---
With latest dmd (git master):
----
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]       true    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]                 true    true    true
int[]                   false   true    true

Test code:
----
import std.stdio, std.typetuple;
void main()
{
    writeln("Rhs is an array, is it compilable?");
    writeln("a\t/ b\t\ta=b\ta[]=b\ta=b[]\ta[]=b[]");
    foreach (i, Lhs; TypeTuple!(int[3], int[]))
    foreach (j, Rhs; TypeTuple!(int[3], int[]))
    {
        writef("%s\t/ %s  ", Lhs.stringof, Rhs.stringof);
        Lhs a = [0,0,0];
        Rhs b = [1,2,3];
        writef("\t%s", is(typeof({ a   = b;   })));
        writef("\t%s", is(typeof({ a[] = b;   })));
        writef("\t%s", is(typeof({ a   = b[]; })));
        writef("\t%s", is(typeof({ a[] = b[]; })));
        writeln();
    }
    writeln("\nRhs is a element, is it compilable?");
    writeln("a\t\t\ta=N\ta[]=N\ta[0..2]=N");
    foreach (Lhs; TypeTuple!(int[3], int[]))
    {
        writef("%s\t\t", Lhs.stringof);
        Lhs a = [0,0,0];
        writef("\t%s", is(typeof({ a       = 9; })));
        writef("\t%s", is(typeof({ a[]     = 9; })));
        writef("\t%s", is(typeof({ a[0..2] = 9; })));
        writeln();
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 02 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971






 With latest dmd (git master):


Very nice. See:

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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 15 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971






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


This is from that post:

This also means this is currently accepted:

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


While 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[]
}



I'd like D to require  a[]=1  in that first case too.

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.

On the other hand Don says that [] is only required for lvalues.

I think this boils to a new table like this:


Rhs is an array, is it compilable?
a       / b             a=b     a[]=b   a=b[]   a[]=b[]
int[3u] / int[3u]       FALSE   true    FALSE   true
int[3u] / int[]         FALSE   true    FALSE   true
int[]   / int[3u]       FALSE   true    FALSE   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


Now if there's a [] on the left, then it's an O(n) vector operation (like a
copy), otherwise it's O(1).

That also means:

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

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


I am not sure this new table is fully correct, but it's a start. Fixes of
mistakes are welcomes.

-----------------------

This is an alternative proposal.

On the other hand this vector op syntax doesn't currently compile:

void main() {
    int[3] a, b;
    a[] += b;
}


So if array assign is seen as a normal vector op, then the [] is needed on the
right too:


Rhs is an array, is it compilable?
a       / b             a=b     a[]=b   a=b[]   a[]=b[]
int[3u] / int[3u]       FALSE   FALSE   FALSE   true
int[3u] / int[]         FALSE   FALSE   FALSE   true
int[]   / int[3u]       FALSE   FALSE   FALSE   true
int[]   / int[]         true    FALSE   FALSE   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


Where the two cases with dynamic arrays are syntax errors to keep more
symmetry:

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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 15 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971


timon.gehr gmx.ch changed:

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



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: -------
Nov 19 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971






 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: -------
Nov 19 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




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: -------
Nov 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971


yebblies <yebblies gmail.com> changed:

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





 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: -------
Feb 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971







 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: -------
Feb 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




Eventually?  Why not now?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971






 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: -------
Feb 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




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: -------
Feb 05 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971




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: -------
Feb 05 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3971


bearophile_hugs eml.cc changed:

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



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: -------
Feb 05 2012