this is accepted by DMD:
int[] a0 = new int[256];
and this is not:
int[][] a1 = new int[256][256];
what i'm expecting is that second sample will be the same as:
int[][] a1 = new int[][](256, 256);
currently DMD complains that it "cannot implicitly convert expression (new int[256][](256u)) of type int[256][] to int[][]".
Comment #1 by bearophile_hugs — 2014-09-29T07:29:03Z
I suspect that the array creation syntax is an unfixable mess.
new int[256][256] can also be generate a pointer to fixed size array int[256][256].
Comment #2 by ketmar — 2014-09-29T08:18:09Z
(In reply to bearophile_hugs from comment #1)
> I suspect that the array creation syntax is an unfixable mess.
>
> new int[256][256] can also be generate a pointer to fixed size array
> int[256][256].
this can be easily fixed: `new [256][256]` => `new [][](256, 256)`, and `new ([256])[256]` => `new [256][](256)`.
i.e. to generate array of 256 `ubyte[256]` one can add parens. this way `[256][256]` will be intuitive and '256*ubyte[256]' is possible.
or just kill then `new [n]` syntax altogether, so people will not try `new [n][m]`.
Comment #3 by k.hara.pg — 2014-10-02T05:02:29Z
(In reply to bearophile_hugs from comment #1)
> I suspect that the array creation syntax is an unfixable mess.
>
> new int[256][256] can also be generate a pointer to fixed size array
> int[256][256].
I think all dynamic array allocation should be writtten as:
int[][](1, 2)
Current ambituity syntax new int[2][1] should be deprecated, removed,
and then we can reuse it for static array allocation.
Comment #4 by bearophile_hugs — 2014-10-02T09:19:19Z
(In reply to Kenji Hara from comment #3)
> Current ambituity syntax new int[2][1] should be deprecated, removed,
> and then we can reuse it for static array allocation.
I suggest you to make you usual long table of all possible combinations, to show me what to allow and what to deprecate :-) If we manage to improve the array creation syntax it's going to be a significant improvement for D, because I use arrays all the time.
Comment #5 by smjg — 2014-11-09T17:39:48Z
(In reply to Ketmar Dark from comment #0)
> this is accepted by DMD:
>
> int[] a0 = new int[256];
>
> and this is not:
>
> int[][] a1 = new int[256][256];
This isn't meant to work. int[][] is a dynamic array of dynamic arrays, not a rectangular array. That is, it's a (length, pointer) tuple, which points to the elements each of which is a (length, pointer) tuple.
On the other hand, new int[256][256] is of type int[256][] - a dynamic array of static arrays.
(In reply to Kenji Hara from comment #3)
> Current ambituity syntax new int[2][1] should be deprecated, removed,
> and then we can reuse it for static array allocation.
What exactly are you wanting that's different from what it already does?
Comment #6 by ketmar — 2014-11-09T18:40:41Z
(In reply to Stewart Gordon from comment #5)
i understand why it's not working as one expecting. but i'm talking about "principle of least astonishment" (ah, this is sore spot of D…).
people are not computers. my common sense tells me that if `int[] a0 = new int[256];` works by creating 256-element array of ints, then ` int[][] a1 = new int[256][256];` should create 256x256 element matrix. but D is constantly fighting with common sense, i'm starting to get used to this. ;-)
Comment #7 by dennis.m.ritchie — 2015-05-30T22:13:12Z
(In reply to Kenji Hara from comment #3)
> (In reply to bearophile_hugs from comment #1)
> > I suspect that the array creation syntax is an unfixable mess.
> >
> > new int[256][256] can also be generate a pointer to fixed size array
> > int[256][256].
>
> I think all dynamic array allocation should be writtten as:
>
> int[][](1, 2)
>
> Current ambituity syntax new int[2][1] should be deprecated, removed,
> and then we can reuse it for static array allocation.
Now D is used for a multidimensional array syntax :)
auto arrray = new int[][][][][][][][][][][](4, 8, 6, 13 /* ... The length of the other subarrays on request */);
I suggest to implement such a syntax for declaring multidimensional arrays:
auto array = new int[11](4, 8, 6, 13 /* .... The length of the other subarrays on request */);
P.S. The syntax for declaring multidimensional arrays, needs work!
Comment #8 by dennis.m.ritchie — 2015-05-30T22:18:00Z
> Current ambituity syntax new int[2][1] should be deprecated, removed,
> and then we can reuse it for static array allocation.
Quickly already, the problems with static arrays in D are boring.
Comment #9 by ketmar — 2015-05-30T22:39:56Z
(In reply to dennis.m.ritchie from comment #7)
> I suggest to implement such a syntax for declaring multidimensional arrays:
>
> auto array = new int[11](4, 8, 6, 13 /* .... The length of the other
> subarrays on request */);
you can do almost the same with templates.
auto DNew(T, A...) () if (A.length > 0) {
template A2S(A...) {
import std.conv : to;
static if (A.length == 0)
enum A2S = "";
else
enum A2S = to!string(A[0])~","~A2S!(A[1..$]);
}
import std.array : replicate;
return mixin("new "~T.stringof~"[]".replicate(A.length)~"("~A2S!A~")");
}
void main () {
import std.stdio;
auto a = DNew!(int, 5, 6, 7);
a[2][3][4] = 42;
writeln(a[2][3][]);
}
Comment #10 by dennis.m.ritchie — 2015-05-31T00:29:35Z
(In reply to Ketmar Dark from comment #9)
> (In reply to dennis.m.ritchie from comment #7)
> > I suggest to implement such a syntax for declaring multidimensional arrays:
> >
> > auto array = new int[11](4, 8, 6, 13 /* .... The length of the other
> > subarrays on request */);
>
> you can do almost the same with templates.
>
> auto DNew(T, A...) () if (A.length > 0) {
> template A2S(A...) {
> import std.conv : to;
> static if (A.length == 0)
> enum A2S = "";
> else
> enum A2S = to!string(A[0])~","~A2S!(A[1..$]);
> }
> import std.array : replicate;
> return mixin("new "~T.stringof~"[]".replicate(A.length)~"("~A2S!A~")");
> }
>
>
> void main () {
> import std.stdio;
> auto a = DNew!(int, 5, 6, 7);
> a[2][3][4] = 42;
> writeln(a[2][3][]);
> }
Yes, do that D is really easy!
Then why in the D still has not gotten rid of this hardcore syntax :)
auto a = new int[][][](5, 6, 7);
Surely this is an attempt to maintain compatibility with C?
Comment #11 by dennis.m.ritchie — 2015-05-31T00:31:20Z
> Surely this is an attempt to maintain compatibility with C?
With C++ :)
Comment #12 by robert.schadek — 2024-12-13T18:30:08Z