[Issue 23420] New: Deprecate mixing pointer/reference types and value types in the same assignment statement

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=23420

          Issue ID: 23420
           Summary: Deprecate mixing pointer/reference types and value
                    types in the same assignment statement
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P1
         Component: dmd
          Assignee: nobody at puremagic.com
          Reporter: mingwu at gmail.com

>From the discussion of:

https://forum.dlang.org/thread/vxoyzscaulbgghmmftub@forum.dlang.org?page=1

Hi,

import std.stdio;

void main() {
        int[3] arr;
        writeln(arr);
        arr = new int[5];
        writeln(arr);
}


$ dmd static_array.d
$ ./static_array
[0, 0, 0]
core.exception.RangeError at static_array.d(6): Range violation
----------------
??:? _d_arrayboundsp [0x55e4830afcb5]
??:? _Dmain [0x55e48308f957]


$ ldc2 static_array.d
$ ./static_array
[0, 0, 0]
Illegal instruction (core dumped)

Why this code can be compiled and causing runtime error? it should be caught at
compile time!
-----------

This is so confusing:

arr = other;  // assign array variable to `other`

arr[] = other[];  // assign array contents

I think D has the second form already, then the first form should not be a
shorthand for the second form.

-----------

Regarding the syntax problem I want to make my point clear again: different
semantics (variable assignment a = b v.s content assignment a[] = b[]) should
have different syntax, *regardless* they are static or dynamic array.

Of course, with these different syntax, the compiler can do more for static
checking, this is what I expected compiler behavior:

```
  int[3] a;            // compiler know it's a static array
  a = b;               // compiler issue error: static array cannot be
re-assigned
  a = new int[5];      // compiler issue error: static array cannot be
re-assigned
  a = new int[3];      // compiler issue error: static array cannot be
re-assigned

  a = what_ever_here;  // compiler issue error: static array cannot be
re-assigned

  a[] = b[];    // content assignment ok; but if b's size can be known
statically at compile time and is different from 3, issue error at compile
time; otherwise run time error.

  a[start_a .. end_b] = b[start_b .. end_b];  // same as above, content
assignment
```

-----------
Current D compiler behavior:
>     a = b;     // Error: mismatched array lengths, 3 and 5
>     a[] = b[]; // Error: mismatched array lengths, 3 and 5

This is what I'm against.

currently these two statements have the same semantics (content assignment).

While the 1st statement should just be var assignment, which does NOT need to
check length at all, the error message should be "Error: static array cannot be
re-assigned".

-----------
> That is not excuse to mix two different semantics into one syntax.
>
> Especially D has `static if`.

The exact same "semantic mixing" also occurs between classes and structs:

    class C
    {
        int n;
        this(int n) { this.n = n; }
    }

    struct S
    {
        int n;
    }

    void main()
    {
        C c1 = new C(123);
        C c2;
        c2 = c1;
        c1.n = 456;
        assert(c2.n == 456); // "var reassignment"

        S s1 = S(123);
        S s2;
        s2 = s1;
        s1.n = 456;
        assert(s2.n == 123); // "content reassignment"
    }

Should we also have two separate syntaxes for these assignments?

--------

Not in this case, because

1) there is no confusion here about struct v.s class.
2) the array example has alternative and much clear syntax a[] = b[]


And, if we continue with your (value v.s reference type) example, and do the
equivalent in my OP example:

     s1 = new S;

You got:
onlineapp.d(29): Error: cannot implicitly convert expression `new S(0)` of type
`S*` to `S`

This error message is *exactly* what I wanted for my OP example for arrays!

----------

Yes, I agree that this should be an error for arrays too--you should not be
able to mix pointer/reference types and value types in the same assignment.

--