I can do:

int[3] arr = void;
arr[] = 1;

But apparently I can't do:

int[3][4] arr = void;
arr[][] = 1;

What is the best way? What am I missing?

On Saturday, 22 April 2017 at 20:51:46 UTC, XavierAP wrote:
> I can do:
>
> int[3] arr = void;
> arr[] = 1;
>
> But apparently I can't do:
>
> int[3][4] arr = void;
> arr[][] = 1;
>
> What is the best way? What am I missing?

int[3][4] arr = void;
(cast(int[]) arr)[] = 1;
assert(arr[3][2] == 1);

On Saturday, 22 April 2017 at 22:25:58 UTC, kinke wrote:
>
> int[3][4] arr = void;
> (cast(int[]) arr)[] = 1;
> assert(arr[3][2] == 1);

Thanks... I think I prefer to write two loops though :p I wish D built-in arrays supported [,] indexing notation like C# (or as you can do in D for custom types)

On 04/22/2017 01:51 PM, XavierAP wrote:
> I can do:
>
> int[3] arr = void;
> arr[] = 1;
>
> But apparently I can't do:
>
> int[3][4] arr = void;
> arr[][] = 1;
>
> What is the best way? What am I missing?

It took me a while to convince myself that there is no bug here. The problem, as is obvious to others, ;) a whole slice of a whole slice is still the same slice. So it's not possible to go deeper into the element slices. Here is a proof with a simple array:

    int[] a;
    static assert(is(typeof(a[]) == typeof(a[][][][])));

Ali

On Sunday, 23 April 2017 at 09:06:35 UTC, Ali Çehreli wrote:
>
> It took me a while to convince myself that there is no bug here. The problem, as is obvious to others, ;) a whole slice of a whole slice is still the same slice.

Ha, you're right, I hadn't realized.

But I still have a problem. For both multi-dimensional and uni-dimensional arrays a[] and a[][] are the same. And yet, a[] has different type in both cases and a[]=1 compiles for uni-dimensional but not for multi-dimensional.

On 04/23/2017 12:04 PM, XavierAP wrote:

> For both multi-dimensional and
> uni-dimensional arrays a[] and a[][] are the same. And yet, a[] has
> different type in both cases and a[]=1 compiles for uni-dimensional but
> not for multi-dimensional.

I think it's still consistent because the element type is not int in the case of multi-dimensional arrays. The following makes sense to me but I haven't profiled it. Otherwise, kinke's solution is perfectly fine in a system programming language. ;)

    int[3] a;
    a[] = 1;
    a[][] = 1;  // Same effect

    int[3][4] b;
    b[] = [1, 1, 1];
    b[][] = [1, 1, 1];  // Same effect

Ali

On Tuesday, 25 April 2017 at 20:46:24 UTC, Ali Çehreli wrote:
>
> I think it's still consistent because the element type is not int in the case of multi-dimensional arrays.
> [...]
>     int[3][4] b;
>     b[] = [1, 1, 1];

It is consistent, I just miss the possibility to more easily initialize multi-dimensional arrays uniformly in the same way as uni-dimensional ones.

I do not mean it would be good to change the current behavior. I think the best solution would be for D to implement built-in truly multi-dimensional arrays like T[,] as well as the existing (jagged) arrays of arrays T[][]. That's what C# does. The former could maybe even be lowered into jagged arrays (together with their initializations and slicings).

But again most people probably don't miss T[,] built-in arrays, specially since we can implement such [,] indexing for custom types. So there's not a strong use case.

But actually where I'm using multi-dimensional built-in arrays right now is in the private storage of a custom multi-dimensional type. Then I have the choice of either use them and live with this, but forward indexing transparently; or use uni-dimensional as private storage and map from 2d to linear during indexing...