On Saturday, 15 October 2022 at 19:58:12 UTC, rassoc wrote:
>     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".

On Saturday, 15 October 2022 at 20:05:25 UTC, mw wrote:
> 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".

Static arrays can be reassigned, though:

    int[3] a = [1, 2, 3];
    int[3] b = [4, 5, 6];
    b = a;
    a[0] = 4;
    assert(b == [1, 2, 3]);

A static array is a value type, so reassigning one is the same as reassigning any other value type, like an int or a struct--it creates a copy of the data.

The actual problem is that D lets you mix static arrays (which are value types) and slices (which are reference types) in the same assignment.

On Sunday, 16 October 2022 at 00:27:56 UTC, Paul Backus wrote:
> On Saturday, 15 October 2022 at 20:05:25 UTC, mw wrote:
>> 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".
>
> Static arrays can be reassigned, though:
>
>     int[3] a = [1, 2, 3];
>     int[3] b = [4, 5, 6];
>     b = a;
>     a[0] = 4;
>     assert(b == [1, 2, 3]);

From the context of this discussion thread, "var reassign" to static array means: change a.ptr to where it pointing to, i.e the address. And "content assignment" means: change the content of the array (but not the a.ptr, the address).

You example here is "content assignment".

My main point is these two different assignments shouldn't use the same syntax, regardless they are static or dynamic array.

On Sunday, 16 October 2022 at 01:54:51 UTC, mw wrote:
> On Sunday, 16 October 2022 at 00:27:56 UTC, Paul Backus wrote:
>>
>> Static arrays can be reassigned, though:
>>
>>     int[3] a = [1, 2, 3];
>>     int[3] b = [4, 5, 6];
>>     b = a;
>>     a[0] = 4;
>>     assert(b == [1, 2, 3]);
>
> From the context of this discussion thread, "var reassign" to static array means: change a.ptr to where it pointing to, i.e the address. And "content assignment" means: change the content of the array (but not the a.ptr, the address).

A static array doesn't have a ptr runtime field.

> You example here is "content assignment".
>
> My main point is these two different assignments shouldn't use the same syntax, regardless they are static or dynamic array.

There is no problem with assigning a static array to another, because the lengths are always checked at compile time. A static array is a value type so assignment needs to be supported for generic code.

On Sunday, 16 October 2022 at 09:04:59 UTC, Nick Treleaven wrote:
> On Sunday, 16 October 2022 at 01:54:51 UTC, mw wrote:
>> On Sunday, 16 October 2022 at 00:27:56 UTC, Paul Backus wrote:
>>>
>>> Static arrays can be reassigned, though:
>>>
>>>     int[3] a = [1, 2, 3];
>>>     int[3] b = [4, 5, 6];
>>>     b = a;
>>>     a[0] = 4;
>>>     assert(b == [1, 2, 3]);
>>
>> From the context of this discussion thread, "var reassign" to static array means: change a.ptr to where it pointing to, i.e the address. And "content assignment" means: change the content of the array (but not the a.ptr, the address).
>
> A static array doesn't have a ptr runtime field.

Someone showed this code very earlier in this thread already:


void main() {
     int[3] arr;
     writeln(arr.ptr);
}

Output:
7FFC1A072820


>> You example here is "content assignment".
>>
>> My main point is these two different assignments shouldn't use the same syntax, regardless they are static or dynamic array.
>
> There is no problem with assigning a static array to another, because the lengths are always checked at compile time.

Not in my OP example.

> A static array is a value type so assignment needs to be supported for generic code.

That is not excuse to mix two different semantics into one syntax.

Especially D has `static if`.

On Sunday, 16 October 2022 at 11:47:35 UTC, mw wrote:
> On Sunday, 16 October 2022 at 09:04:59 UTC, Nick Treleaven wrote:
.
>>
>> A static array doesn't have a ptr runtime field.
>
> Someone showed this code very earlier in this thread already:
>
>
> void main() {
>      int[3] arr;
>      writeln(arr.ptr);
> }
>
> Output:
> 7FFC1A072820
>
>

Keyword: "runtime". Try to assign a new value to the `.ptr` property and see what happens.

On Sunday, 16 October 2022 at 11:50:02 UTC, Mike Parker wrote:
> On Sunday, 16 October 2022 at 11:47:35 UTC, mw wrote:
>> On Sunday, 16 October 2022 at 09:04:59 UTC, Nick Treleaven wrote:
> .
>>>
>>> A static array doesn't have a ptr runtime field.
>>
>> Someone showed this code very earlier in this thread already:
>>
>>
>> void main() {
>>      int[3] arr;
>>      writeln(arr.ptr);
>> }
>>
>> Output:
>> 7FFC1A072820
>>
>>
>
> Keyword: "runtime". Try to assign a new value to the `.ptr` property and see what happens.

Well, I printed it at "runtime".


Again, I know that, and I want the compiler to help me catch the problem in my OP example.


Even if you mean "modifiable" at runtime, dynamic array's .ptr behaves the same:

void main() {
     int[] arr;
     arr.ptr = 0;
     writeln(arr.ptr);
}

onlineapp.d(5): Error: `arr.ptr` is not an lvalue and cannot be modified

On Sunday, 16 October 2022 at 11:47:35 UTC, mw wrote:
> 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?

On Sunday, 16 October 2022 at 14:19:55 UTC, Paul Backus wrote:
> On Sunday, 16 October 2022 at 11:47:35 UTC, mw wrote:
>> 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!

Thank you for this example.

On Sunday, 16 October 2022 at 16:38:56 UTC, mw wrote:
> 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.

But if both sides of the assignment are the *same* type, then there is no confusion, and no need to use a different syntax.