Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"

[Ali Çehreli via Digitalmars-d-announce]

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 at 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