digitalmars.D - why static array can be reassigned with new allocation?

mw (23/23) Oct 14 2022 Hi,

jfondren (25/27) Oct 14 2022 ```d

rassoc (2/3) Oct 15 2022 Try compiling with -release for extra fun, or not.

Nick Treleaven (3/7) Oct 15 2022 Use `@safe` then you still get bounds checks with `-release`. (Or
Tejas (10/14) Oct 15 2022 It printed the arrays

Timon Gehr (5/19) Oct 15 2022 The code has UB with -release, but it is a different case. There are no

mw (16/38) Oct 15 2022 This is so confusing, we should have two different syntax for

Tejas (2/19) Oct 15 2022 +1
rassoc (10/16) Oct 15 2022 These python arrays aren't static though.

mw (11/31) Oct 15 2022 you can always specify the start, end index:

rassoc (11/13) Oct 15 2022 They are not the same thing and behave differently for dynamic and stati...

mw (11/29) Oct 15 2022 Regarding the syntax problem I want to make my point clear again:

mw (17/21) Oct 15 2022 Of course, with these different syntax, the compiler can do more

rassoc (15/28) Oct 15 2022 Static array doesn't mean they can't be mutable; they are simply stack a...

mw (7/9) Oct 15 2022 This is what I'm against.

Paul Backus (13/16) Oct 15 2022 Static arrays can be reassigned, though:

mw (8/18) Oct 15 2022 From the context of this discussion thread, "var reassign" to

Nick Treleaven (6/22) Oct 16 2022 There is no problem with assigning a static array to another,

mw (11/35) Oct 16 2022 Someone showed this code very earlier in this thread already:

Mike Parker (4/15) Oct 16 2022 Keyword: "runtime". Try to assign a new value to the `.ptr`

mw (13/34) Oct 16 2022 Well, I printed it at "runtime".

Paul Backus (26/29) Oct 16 2022 The exact same "semantic mixing" also occurs between classes and

mw (14/44) Oct 16 2022 Not in this case, because

Paul Backus (6/14) Oct 16 2022 Yes, I agree that this should be an error for arrays too--you

mw (4/14) Oct 15 2022 Sorry, I just realized that `a = b.dup` is also var assignment:

=?UTF-8?Q?Ali_=c3=87ehreli?= (7/10) Oct 14 2022 That syntax is confusing. Although it looks like a static array, it's a

matheus (4/9) Oct 15 2022 Yes but in this case it's known during the compiling time

Nick Treleaven (10/18) Oct 15 2022 It would be better to error on assigning a new array expression
Per =?UTF-8?B?Tm9yZGzDtnc=?= (12/21) Oct 16 2022 It could. And it's not hard to add it but I'm not sure it would

mw (6/20) Oct 16 2022 The main problem in the OP example is that: mixing
Per =?UTF-8?B?Tm9yZGzDtnc=?= (10/10) Oct 16 2022 On Sunday, 16 October 2022 at 20:26:58 UTC, Per Nordlöw wrote:

Nick Treleaven (11/19) Oct 15 2022 I recently updated the docs to prefer the `new E[](length)` form

Nick Treleaven (2/13) Oct 15 2022 Looks like an LDC bug.

mw <mingwu gmail.com> writes:

Hi,

``` static_array.d
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 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!

Oct 14 2022

jfondren <julian.fondren gmail.com> writes:

On Friday, 14 October 2022 at 18:57:44 UTC, mw wrote:
 Why this code can be compiled and causing runtime error? it 
 should be caught at compile time!

```d
import std.stdio;

void main() {
     int[3] arr;
     writeln(arr.ptr);
     arr = new int[3];
     writeln(arr.ptr);
     writeln(typeid(arr));
}
```

output (e.g.):

```
7FFD5EBF1530
7FFD5EBF1530
int[3]
```

It's not a reassignment of arr, but a copying of the contents of 
the dynamic array, and it crashes with an oversized array as the 
lengths don't match, same as if you did

```d
     int[] other = new int[5];
     foreach (i; 0 .. other.length)
         arr[i] = other[i];
```

Oct 14 2022

rassoc <rassoc posteo.de> writes:

On 10/14/22 21:46, jfondren via Digitalmars-d wrote:
 and it crashes with an oversized array as the lengths don't match

Try compiling with -release for extra fun, or not.

Oct 15 2022

Nick Treleaven <nick geany.org> writes:

On Saturday, 15 October 2022 at 11:29:00 UTC, rassoc wrote:
 On 10/14/22 21:46, jfondren via Digitalmars-d wrote:
 and it crashes with an oversized array as the lengths don't 
 match

 Try compiling with -release for extra fun, or not.

Use ` safe` then you still get bounds checks with `-release`. (Or 
don't use `-release`).

Oct 15 2022

Tejas <notrealemail gmail.com> writes:

On Saturday, 15 October 2022 at 11:29:00 UTC, rassoc wrote:
 On 10/14/22 21:46, jfondren via Digitalmars-d wrote:
 and it crashes with an oversized array as the lengths don't 
 match

 Try compiling with -release for extra fun, or not.

It printed the arrays
  ```
[0, 0, 0]
[0, 0, 0]
```
... lol did it cache the results of the previous call? Somebody 
please explain this, is this what Timon meant by undefined 
behaviour getting introduced in programs whose `assert`s get 
removed from the code?

Oct 15 2022

Timon Gehr <timon.gehr gmx.ch> writes:

On 15.10.22 14:10, Tejas wrote:
 On Saturday, 15 October 2022 at 11:29:00 UTC, rassoc wrote:
 On 10/14/22 21:46, jfondren via Digitalmars-d wrote:
 and it crashes with an oversized array as the lengths don't match

 Try compiling with -release for extra fun, or not.

 
 It printed the arrays
   ```
 [0, 0, 0]
 [0, 0, 0]
 ```
 ... lol did it cache the results of the previous call? Somebody please 
 explain this, is this what Timon meant by undefined behaviour getting 
 introduced in programs whose `assert`s get removed from the code?

The code has UB with -release, but it is a different case. There are no 
asserts in it. Currently, failing asserts introduce UB in -release even 
if they are not guarding against anything that would ordinarily cause 
UB. I think that's not justifiable.

Oct 15 2022

mw <mingwu gmail.com> writes:

On Friday, 14 October 2022 at 19:46:06 UTC, jfondren wrote:
 On Friday, 14 October 2022 at 18:57:44 UTC, mw wrote:
 Why this code can be compiled and causing runtime error? it 
 should be caught at compile time!

 ```d
 import std.stdio;

 void main() {
     int[3] arr;
     writeln(arr.ptr);
     arr = new int[3];
     writeln(arr.ptr);
     writeln(typeid(arr));
 }
 ```

 output (e.g.):

 ```
 7FFD5EBF1530
 7FFD5EBF1530
 int[3]
 ```

 It's not a reassignment of arr, but a copying of the contents 
 of the dynamic array, and it crashes with an oversized array as 
 the lengths don't match,

This is so confusing, we should have two different syntax for 
this two different semantics:
```
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.

These two have two different semantics.

If you view the above two statements as in Python (numpy), it's 
very clear their meaning are different:
``` Python
arr = other;  // assign array variable to `other`

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

Oct 15 2022

Tejas <notrealemail gmail.com> writes:

On Saturday, 15 October 2022 at 16:20:51 UTC, mw wrote:
 On Friday, 14 October 2022 at 19:46:06 UTC, jfondren wrote:
 [...]

 This is so confusing, we should have two different syntax for 
 this two different semantics:
 ```
 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.

 These two have two different semantics.

 If you view the above two statements as in Python (numpy), it's 
 very clear their meaning are different:
 ``` Python
 arr = other;  // assign array variable to `other`

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



+1

Oct 15 2022

rassoc <rassoc posteo.de> writes:

On 10/15/22 18:20, mw via Digitalmars-d wrote:
 If you view the above two statements as in Python (numpy), it's very clear
their meaning are different:
 ``` Python
 arr = other;  // assign array variable to `other`

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

These python arrays aren't static though.

Also, good old python will give you a view/slice of the whole array in the
later case, not element-wise assignment. Numpy works differently and will fail
if your shapes aren't the same:

  >>> a = np.array([1,2,3])
  >>> b = np.array([1,2,3,4,5])
  >>> a[:] = b[:]
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ValueError: could not broadcast input array from shape (5,) into shape (3,)

Not all that different from your initial static array example.

Oct 15 2022

mw <mingwu gmail.com> writes:

On Saturday, 15 October 2022 at 17:09:53 UTC, rassoc wrote:
 On 10/15/22 18:20, mw via Digitalmars-d wrote:
 If you view the above two statements as in Python (numpy), 
 it's very clear their meaning are different:
 ``` Python
 arr = other;  // assign array variable to `other`

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

 These python arrays aren't static though.

 Also, good old python will give you a view/slice of the whole 
 array in the later case, not element-wise assignment. Numpy 
 works differently and will fail if your shapes aren't the same:

  >>> a = np.array([1,2,3])
  >>> b = np.array([1,2,3,4,5])
  >>> a[:] = b[:]
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ValueError: could not broadcast input array from shape (5,) 
 into shape (3,)

 Not all that different from your initial static array example.

you can always specify the start, end index:

```
a[start_a: end_a] = b[start_b: end_b]
```

It will fail if the length does not match; or even you can argue 
that it's also runtime error (right, Python is not static 
compiled language).

But the main point I want to make is: these two different 
semantics should have different syntax, do not overload as it 
only confuse the programmer.

Oct 15 2022

rassoc <rassoc posteo.de> writes:

On 10/15/22 19:18, mw via Digitalmars-d wrote:
 But the main point I want to make is: these two different semantics should
have different syntax, do not overload as it only confuse the programmer.
 

They are not the same thing and behave differently for dynamic and static
arrays. Furthermore, there's a distinction between dynamic arrays and slices:
ownership of data. [1]

But what you are probably looking for is the follow which is behaving the same
as in python:

import std.stdio : writeln;
void main() {
     auto a = [1,2,3];
     auto b = [1,2,3,4,5];
     a = b.dup;
     writeln(a is b, " ", a == b); // false true
}

[1] https://dlang.org/articles/d-array-article.html

Oct 15 2022

mw <mingwu gmail.com> writes:

On Saturday, 15 October 2022 at 18:22:10 UTC, rassoc wrote:
 On 10/15/22 19:18, mw via Digitalmars-d wrote:
 But the main point I want to make is: these two different 
 semantics should have different syntax, do not overload as it 
 only confuse the programmer.
 

 They are not the same thing and behave differently for dynamic 
 and static arrays. Furthermore, there's a distinction between 
 dynamic arrays and slices: ownership of data. [1]

 But what you are probably looking for is the follow which is 
 behaving the same as in python:

 import std.stdio : writeln;
 void main() {
     auto a = [1,2,3];
     auto b = [1,2,3,4,5];
     a = b.dup;
     writeln(a is b, " ", a == b); // false true
 }

 [1] https://dlang.org/articles/d-array-article.html


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.

As more fun with your example:

      a = b.dup;  // so this is content assignment?
      writeln(a is b, " ", a == b); // false true

      a = b;      // this is var assignment?
      writeln(a is b, " ", a == b); // true true

This current syntax in D is as clear as mud.

Oct 15 2022

mw <mingwu gmail.com> writes:

On Saturday, 15 October 2022 at 18:44:04 UTC, mw wrote:
 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:

```
   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 = 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
```

Oct 15 2022

rassoc <rassoc posteo.de> writes:

On 10/15/22 20:56, mw via Digitalmars-d wrote:
 Of course, with these different syntax, the compiler can do more for static
checking:
 
 ```
    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 = 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
 ``` 

Static array doesn't mean they can't be mutable; they are simply stack
allocated and value types.

Also, that checking will be done when it's only static arrays:

import std;
void main() {
     int[3] a;
     int[5] b;
     a = b;     // Error: mismatched array lengths, 3 and 5
     a[] = b[]; // Error: mismatched array lengths, 3 and 5
     a[10] = 0; // Error: array index 10 is out of bounds `a[0 .. 3]`
}

D, as of right now, doesn't do these compile-time checks when dynamic arrays
are involved even if it could, which isn't optimal, I agree.

 This current syntax in D is as clear as mud.

Maybe these links help:

Cloning: https://forum.dlang.org/post/mailman.3.1473548067.2994.digitalmars-d-learn puremagic.com
Array types and ops: https://dlang.org/spec/arrays.html

Oct 15 2022

mw <mingwu gmail.com> writes:

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".

Oct 15 2022

Paul Backus <snarwin gmail.com> writes:

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.

Oct 15 2022

mw <mingwu gmail.com> writes:

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.

Oct 15 2022

Nick Treleaven <nick geany.org> writes:

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.

Oct 16 2022

mw <mingwu gmail.com> writes:

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`.

Oct 16 2022

Mike Parker <aldacron gmail.com> writes:

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.

Oct 16 2022

mw <mingwu gmail.com> writes:

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

Oct 16 2022

Paul Backus <snarwin gmail.com> writes:

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?

Oct 16 2022

mw <mingwu gmail.com> writes:

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.

Oct 16 2022

Paul Backus <snarwin gmail.com> writes:

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.

Oct 16 2022

mw <mingwu gmail.com> writes:

On Saturday, 15 October 2022 at 18:44:04 UTC, mw wrote:
 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.

 As more fun with your example:

      a = b.dup;  // so this is content assignment?
      writeln(a is b, " ", a == b); // false true

Sorry, I just realized that `a = b.dup` is also var assignment: 
b.dup will create a new array and assigned to a, hence `a is b` 
is false.

      a = b;      // this is var assignment?
      writeln(a is b, " ", a == b); // true true

 This current syntax in D is as clear as mud.

Oct 15 2022

=?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:

On 10/14/22 11:57, mw wrote:

      arr = new int[5];

That syntax is confusing. Although it looks like a static array, it's a 
dynamic array of length 5.

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

The compiler does not perform detailed analysis of all code. Since that 
5 could be a runtime expression, the compiler does not check it at 
compile time.

Ali

Oct 14 2022

matheus <matheus gmail.com> writes:

On Friday, 14 October 2022 at 20:19:20 UTC, Ali Çehreli wrote:
 ...
 The compiler does not perform detailed analysis of all code. 
 Since that 5 could be a runtime expression, the compiler does 
 not check it at compile time.
 ...

Yes but in this case it's known during the compiling time 
(Literal 5), couldn't this be checked and prevented?

Matheus.

Oct 15 2022

Nick Treleaven <nick geany.org> writes:

On Saturday, 15 October 2022 at 10:31:16 UTC, matheus wrote:
 On Friday, 14 October 2022 at 20:19:20 UTC, Ali Çehreli wrote:
 ...
 The compiler does not perform detailed analysis of all code. 
 Since that 5 could be a runtime expression, the compiler does 
 not check it at compile time.
 ...

 Yes but in this case it's known during the compiling time 
 (Literal 5), couldn't this be checked and prevented?

It would be better to error on assigning a new array expression 
to a static array, there's no reason to allow that. A static 
array can be assigned a single element `arr = 0` instead. 
Although ideally there would be some syntactical way of making it 
clear when assigning a slice to a static array, perhaps requiring 
`[]` at the end unless it is already a SliceExpression or an 
array literal. Then the syntax would tell you if the right hand 
side had a compile-time known length not (and hence you can rely 
on a compile-time error if lengths don't match).

Oct 15 2022

Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

On Saturday, 15 October 2022 at 10:31:16 UTC, matheus wrote:
 On Friday, 14 October 2022 at 20:19:20 UTC, Ali Çehreli wrote:
 ...
 The compiler does not perform detailed analysis of all code. 
 Since that 5 could be a runtime expression, the compiler does 
 not check it at compile time.
 ...

 Yes but in this case it's known during the compiling time 
 (Literal 5), couldn't this be checked a prevented?

 Matheus.

It could. And it's not hard to add it but I'm not sure it would 
be accepted.

We should instead deprecate

’’’d
new T[n]
’’’

in favor of

’’’d
new T[](n)
’’’

.

Oct 16 2022

mw <mingwu gmail.com> writes:

On Sunday, 16 October 2022 at 20:26:58 UTC, Per Nordlöw wrote:
 On Saturday, 15 October 2022 at 10:31:16 UTC, matheus wrote:
 On Friday, 14 October 2022 at 20:19:20 UTC, Ali Çehreli wrote:
 ...
 The compiler does not perform detailed analysis of all code. 
 Since that 5 could be a runtime expression, the compiler does 
 not check it at compile time.
 ...

 Yes but in this case it's known during the compiling time 
 (Literal 5), couldn't this be checked a prevented?


The main problem in the OP example is that: mixing 
pointer/reference types and value types in the same assignment 
statement, and the compiler didn't complain.

I just logged an issue, and think we should deprecate it:

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

 It could. And it's not hard to add it but I'm not sure it would 
 be accepted.

 We should instead deprecate

Oct 16 2022

Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:

On Sunday, 16 October 2022 at 20:26:58 UTC, Per Nordlöw wrote:

I meant we should instead deprecate


```d
new T[n]
```

in favor of

```d
new T[](n)
```

to avoid the syntactic confusion.

Oct 16 2022

Nick Treleaven <nick geany.org> writes:

On Friday, 14 October 2022 at 20:19:20 UTC, Ali Çehreli wrote:
 On 10/14/22 11:57, mw wrote:

      arr = new int[5];

 That syntax is confusing. Although it looks like a static 
 array, it's a dynamic array of length 5.

I recently updated the docs to prefer the `new E[](length)` form 
instead:

 It is preferred to use the Type(ArgumentList) form when 
 allocating dynamic arrays instead, as it is more general.

 Note: It is not possible to allocate a static array directly 
 with new (only by using a type alias).

https://dlang.org/spec/expression.html#NewExpression

At some point the `T[length]` form should be deprecated. Perhaps 
we could have a compiler switch `-strict` that deprecates a set 
of things, e.g. struct postblit. This would be used for anything 
which needs a long deprecation period and to avoid annoying 
people by adding new deprecations spread out over a number of 
releases. Instead they can update their code using the `-strict` 
check once in a while.

Oct 15 2022

Nick Treleaven <nick geany.org> writes:

On Friday, 14 October 2022 at 18:57:44 UTC, mw wrote:

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


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

Looks like an LDC bug.

Oct 15 2022

D Programming

C/C++ Programming

Other

digitalmars.D - why static array can be reassigned with new allocation?