Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inconsistent 'new' syntax for arrays #18893

Open
dlangBugzillaToGithub opened this issue Sep 29, 2014 · 11 comments
Open

inconsistent 'new' syntax for arrays #18893

dlangBugzillaToGithub opened this issue Sep 29, 2014 · 11 comments

Comments

@dlangBugzillaToGithub
Copy link

Ketmar Dark reported this on 2014-09-29T03:15:47Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=13556

CC List

  • Ketmar Dark
  • Stewart Gordon

Description

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[][]".
@dlangBugzillaToGithub
Copy link
Author

bearophile_hugs commented on 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].

@dlangBugzillaToGithub
Copy link
Author

ketmar commented on 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]`.

@dlangBugzillaToGithub
Copy link
Author

k.hara.pg commented on 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.

@dlangBugzillaToGithub
Copy link
Author

bearophile_hugs commented on 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.

@dlangBugzillaToGithub
Copy link
Author

smjg commented on 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?

@dlangBugzillaToGithub
Copy link
Author

ketmar commented on 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. ;-)

@dlangBugzillaToGithub
Copy link
Author

dennis.m.ritchie commented on 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!

@dlangBugzillaToGithub
Copy link
Author

dennis.m.ritchie commented on 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.

@dlangBugzillaToGithub
Copy link
Author

ketmar commented on 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][]);
}

@dlangBugzillaToGithub
Copy link
Author

dennis.m.ritchie commented on 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?

@dlangBugzillaToGithub
Copy link
Author

dennis.m.ritchie commented on 2015-05-31T00:31:20Z

> Surely this is an attempt to maintain compatibility with C?

With C++ :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant