Herb Sutter briefly discusses D during interview

Jonathan M Davis jmdavisProg at gmx.com
Wed Jun 8 01:49:04 PDT 2011


On 2011-06-08 00:54, Ali Çehreli wrote:
> On 06/07/2011 06:30 PM, Jonathan M Davis wrote:
>  > On 2011-06-07 17:53, Andrej Mitrovic wrote:
>  >> I'm not sure what he means when he says that D doesn't simplify syntax.
>  > 
>  > He talked just before that about simplifying declaration syntax so
> 
> that it
> 
>  > reads left-to-right instead of right-to-left, and D didn't do that.
> 
> I don't think D could use right-to-left. Like this?:
> 
> a int;
> p *int;
> 
> That would be too strange for its heritage.
> 
>  > For
>  > instance,
>  > 
>  > int[4][3] a;
>  > 
>  > declares a static array of length three where each element of that
> 
> array is a
> 
>  > static array of length 4 where each of those arrays holds an integer.
> 
> It's
> 
>  > read right-to-left
> 
> Note that D's syntax fixes the horribly broken one of C. And contrary to
> popular belief, only some of C's syntax is right-to-left; notably,
> pointers to arrays and pointers to functions are outside-to-inside.
> 
> I never read declarations from right to left. I doubt that anybody does
> that. "Code is not Literature". (I stole the title of tomorrow's Silicon
> Valley  ACCU talk:
> http://accu.org/index.php/accu_branches/accu_usa/upcoming) Reading
> declarations from right-to-left is cute but there is no value in doing
> so. Besides, there are no "array of"s in that declaration at all. It is
> a coincidence that the C syntax can be read that way with the added "is
> a"s and "of"s.
> 
> In D, type is on the left and the variable name is on the right:
> 
> int i;
> int[4] array;
> int[4][3] array_of_array;
> 
> That is consistent.
> 
>  > and throws people off at least some of the time.
> 
> It must have thrown only the people who could bend their minds to
> somehow accept C's array syntax.
> 
>  > Because,
>  > when you go to index it, it's used left-to-right
> 
> What is left-to-right? Indexing does one thing: it provides access to
> the element with the given number. There is no left nor right in array
> indexing.
> 
>  > auto a = i[3]; //out-of-bounds
> 
> i[3] accesses the element number 3 of i (yes, with the indicated bug).
> There is nothing else. The type of that element is int[4] as it has been
> declared. This has nothing to do with left and right.
> 
>  > D stayed closer to C and C++
>  > and kept the right-to-left declaration synax. That's what he was
> 
> referring to.
> 
> I agree. I can't understand how D's array syntax is not seen as fixing
> C's broken one.

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. The 
compiler doesn't look at the type of a as being an int pointer. It looks at it 
as being a pointer to an int. The * comes first and then the int. 
Understanding how the compiler does it helps with reading stuff like 
complicated function pointers in C, but particularly with simple declarations, 
people just don't look at it that way. However, the compiler itself is 
deciphering the type outward from the variable name, and that's almost always 
from right to left. The exceptions are when declaring static arrays (which go 
on the right and thus read left-to-right) and when declaring C-style function 
pointers, where it ends up going from _both_ right-to-left and left-to-right, 
because the name is in the middle. So, in both C and D, variable declarations 
almost always read right-to-left.

As for static arrays in D, the problem is the disjoint between declarations 
and indexing. 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. 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. Quite a few people in the past have requested 
that

int[4][3] a;

and

int a[4][3];

be the same in D. But because the compiler reads types outward from the 
variable, that doesn't work. So, D's syntax fixes the broken C syntax in the 
sense that the dimensions go with the type instead of the variable name (as 
they should), but it makes it worse in the sense that it means that the 
dimensions are in the opposite order of what most people expect. But fixing 
the dimensions so that they're in the order that most people expect wouldhmnv

- Jonathan M Davis


More information about the Digitalmars-d mailing list