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