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:
int[4]
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."
Ali
