In article <e0km70$18a0$1@digitaldaemon.com>, Walter Bright says...
>
>BCS wrote:
>> If people don't want it, then it just adds unnecessarily to the task of making a compiler.
>
>It doesn't add more than a few lines. See the code in DMD's parser.c that does it.

Yes it does add a lot to the complexity of writing a compiler. This is because, even if parsing them only adds one line of code, someone who wants to write a D compiler needs to understand C-style declarations before they can figure out how to parse them.


In article <e0n30e$156o$1@digitaldaemon.com>, Sebastián E. Peyrott says...
>
>I believe there's no compelling reason to have them removed right now. Deprecating them and putting a clear notice in the docs is the right way to go, IMO, if Walter's certain that they'll need to be removed at some point in the future. For now, if people don't like them, they can just avoid them...
>
>--
>Sebastián.

see above

Hasan Aljudy wrote:
> int (*x[5])[3];       // x is an array of 5 pointers to arrays of 3 ints
> 
> I hate them!
> To be honest, I never understood them; never tried to. This example is
> taken from the docs, and I really don't understand how does it make x an
> array of 5 pointers to arrays of 3 ints!!

It is not that difficult. The declaration syntax is exactly the same as how you use the variable, it is *consistent*. If you don't understand it, then you have a more basic problem. Just keep an operator precedence chart with you or in your head. [] has higher precedence than *, so *x[5] means an array of pointers, not a pointer to an array. If these pointers are arrays, then you can't write *x[5][3] because of the precedence, and so the parenthesis are required.

I think the C style syntax is much cleaner, consistent and straightforward than D because you don't need to reverse things in you head. 'int x[4][8]' declares an 4x8 matrix. The D syntax of 'int[8][4] x' leads you to the wrong direction unless you are really familiar with the reversed notation.

> D has nicer syntax,
> int[3]*[5] x;    // x is an array of 5 pointers to arrays of 3 ints

So... how do you set the 3rd int of the 1st array pointed by x to 6?

  (*x[0])[2] = 6;

Uh oh... you are back to the same C syntax!! Even if you declare the variable using D syntax, you end up using the C syntax to access it. So I just prefer to stick with the C syntax everywhere to keep everything consistent.

Your other example:

> int (*x)(char);

Pretty clear that x is a pointer to a function returning int. The nearest operator to x is *, so x is a pointer to something. Leaving the parenthesis, you have a function call parenthesis right after, indicating that x points to a function. Without the extra parenthesis, like in `int *x(char)´, it would declare a function that returns a pointer, because function call parenthesis have higher precedence than *.

> I personally would like to see them gone. but that's not for me to decide.

If you don't like them, don't use them. So simple...

> I mean, isn't the C-Style declaration syntax considered to be a design flaw in the original C?

No. As far as I know, it was never considered a design flaw, since it is consistent with how you use the declared object.

If we had a postfix pointer dereferencing operator (instead of the
prefix *), like in PASCAL (^), all these declarations would be simpler,
and wouldn't require the extra parenthesis.

If C used a postfix operator for operator dereferencing, like PASCAL's ^, the above two examples would look like:

  int x[5]^[3]; // x is an array[5] of pointers to array[3] of ints
  int x^(char); // x is a pointer to function(char) that returns an int

This would be even better than current D syntax, since you read the declaration naturally from left to right.

Walter Bright wrote:
> Hasan Aljudy wrote:
> 
>> why is foo(y) allowed at the global scope? and why is it disallowed at local scope?!!
> 
> 
> It should be disallowed at global scope as well. I'll add it to the list of bugs to be fixed.

ok, here's another corner case.

Should
foo(*bar)
be allowed as a declaration?
The C-Style declaration syntax allows it, but this makes the D Grammar *not* context free, because foo(*bar) can be a function call, depending on what foo and bar are.

    //I'm using dmd 0.146
    alias int foo;
    foo(*y); //ok
    int(*z); //ok
    static this()
    {
        y = null;
        z = null;
    }
    void main()
    {
        int(*w); //ok
        foo(*x); //error
        x = null;
        w = null;
    }

Also notice how there's no problem with "int" (because it's not an identifier) while there is a problem with foo, even though it's just an alias for int, and supposedly the semantic analyzer sees them as the same thing.

I'm not an expert on CFGs (context free grammars) but I think it's pretty complicated to design a grammar that allows
foo(*bar)[x];
as a declaration, but disallows
foo(*bar);
as a declaration.

Hasan Aljudy wrote:
> ok, here's another corner case.
> 
> Should
> foo(*bar)
> be allowed as a declaration?

No.