On 05/28/2014 03:10 PM, Jonathan M Davis via Digitalmars-d-announce wrote:

> On Tue, 27 May 2014 06:42:41 -1000
> Andrei Alexandrescu via Digitalmars-d-announce
> <digitalmars-d-announce@puremagic.com> wrote:
>   >
> http://www.reddit.com/r/programming/comments/26m8hy/scott_meyers_dconf_2014_keynote_the_last_thing_d/
>   >
>   > https://news.ycombinator.com/newest (search that page, if not found
>   > click "More" and search again)
>   >
>   > https://www.facebook.com/dlang.org/posts/855022447844771
>   >
>   > https://twitter.com/D_Programming/status/471330026168651777
> Fortunately, for the most part, I think that we've avoided the types of
> inconsistencies that Scott describes for C++, but we do definitely have some
> of our own. The ones that come to mind at the moment are:
> 1. The order of the dimensions of multi-dimensional static arrays is backwards
> in comparison to what most everyone expects.

However, those expectations are based on the inside-out syntax of C. Naturally, wanting to be consistent, especially compared to C, D should deviate from that syntax.

>       int[4][5][6] foo;

That is sane: It is alwasy "first the type then the size":

int[1]    good
Animal[2] good

Following from that rule (i.e. first type, then size), how would I have an array of 3 elements where each element is an array of 4 elements. Let's see... Each element is int[4]. There:


Then, I want an array of 3 of those. There:

int[4][3] good

This is one of the commonish arguments in the D forums that I have the strongest opinion because there is no problem with D's syntax at all. It is consistent.

It is consistent even when indexing. The index is for the array:

int[1] a;
a[0];     // the first element of a; it is an int

int[2][3] b;
b[0];     // the first element of b; it is an int[2]

I don't see any problem at all. :)

Remembering that there is no such thing as a multi-dimensional array in D (nor C), it just follows naturally:

b[0][1];  // the second int of the first int[2]

> is the same as
>       int foo[6][5][4];

That's beyond ridiculous. I am glad that D avoided that problem for both function pointers and arrays.

> and has the same dimensions as
>       auto bar = new int[][][](6, 5, 4);

That makes perfect sense to me, because this is a function API, not D syntax. There is no ambiguity in saying "you go deeper into the element sizes as you provide the arguments."


Reply via email to