Herb Sutter briefly discusses D during interview

[Ali Çehreli]

On 06/08/2011 01:49 AM, Jonathan M Davis wrote:

 > No, people don't normally look at declarations such as
 >
 > int* a;
 >
 > as being right to left. But from the compiler's perspective, they are.

I will go a little bit off topic here. If we need to think about what 
the compiler does or how a specific language feature is implemented, 
that language is a failed abstraction. D is not. There shouldn't be any 
need to get into implementation details to describe a language feature.

This used to happen with D slices: some people would point to pictures 
of slices where .ptr pointed to the beginning of some elements in 
memory. That way of describing slices would not work on beginners who 
have no idea on what a pointer is, especially in a language where 
pointers can be avoided for a long time.

 > As for static arrays in D, the problem is the disjoint between 
declarations
 > and indexing.

That's very normal: declaration and indexing are separate. Why should 
they have any resemblance? Perhaps they both use the [] characters. That 
is unfortunate, similar to '*' being used in declaration and 
dereferencing; very different things.

 > They're flipped between the two. Most people expect that the
 > dimensions read left to right for both the declaration and the 
indexing, but
 > they don't.

I am not one of those people. I am used to C's weird inside-out array 
syntax since 1989. I've always cringed at that and I've always 
introduced typedefs to remedy the problem.

// C code
#include <stdio.h>

int main()
{
     char a[4][3];
     printf("%zu\n", sizeof(a[0]));  // prints 3
}

// C code with typedef
#include <stdio.h>

int main()
{
     typedef char Row[4];
     Row a[3];
     printf("%zu\n", sizeof(a[0]));  // NOW PRINTS 4! TIME BOMB?
}

The problem there is the necessity to know that Row is a typedef of some 
other array, so that we should now "see" 'a' as a definition of char 
a[3][4].

I am very happy that D solved that problem:

import std.stdio;

void main()
{
     char[4][3] a;
     writeln(typeof(a[0]).sizeof);   // prints 4
}

import std.stdio;

void main()
{
     alias char[4] Row;
     Row[3] a;
     writeln(typeof(a[0]).sizeof);   // STILL PRINTS 4!
}

I call that consistency.

 > They think that
 >
 > int[4][3] a;
 > auto b = a[3][2];
 >
 > is legal, because they view the left dimension in the declaration as 
being the
 > left when indexing. But it's not. If you used the C syntax,
 >
 > int a[4][3];
 > auto b = a[3][2];
 >
 > then the dimensions _do_ match.

They match in that way, but it is inconsistent. The following 
declaration is in the order of type, size, name:

T[3] a;

And indexing is always array[index]:

a[2];  // a reference to T

Now I am going to replace T with int[4]. It is still in the order of 
type, size, name (I am putting inserting a space to distinguish):

int[4] [3] a;

And indexing is still array[index]:

a[2]; // a reference to int[4];

Since a[2] is a reference to int[4], now I can further index it:

a[2][3];

Consistent.

What I don't agree is seeing [2][3] as a single operation. They are two 
separate indexing operations.

That's how I think to be happy. :)

Ali