www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C-Style declarations, are they here to stay?!! Walter?

reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
<< I don't know if this has been discussed before, but I don't remember 
seeing any discussion about it. If it has been, please direct me to one 
of the old threads that discussed it. >>

I noticed that D supports the klumsy C-Style declarations, like

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

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

I can't say I understand how it works, but when I read the description, 
is makes a lot of sense. It reads right to left:
[5]    array of size 5
*      pointer(s)
[3]    array of size 3
int    int(s)

array of 5 pointers to array of 3 ints!

The only reason I don't understand it right away is because I don't like 
nested complex declarations like this anyway, so I never tried to learn 
how to declare them. However, the D syntax makes alot of sense.

Consider for example this C-Style declaration:
int (*x)(char);

VS this D-Style declaration:
int function(char) x;

Why does D support int (*x)(char); anyway?!

Since D has a more intelligent way of declaring the same things, the 
C-Style syntax is unnecessarily redundant IMHO.

My understanding is that it's supported to attract the C/C++ people and 
get them familiarized with D quickly.

But, does this mean that C-Style declarations are gonna stay with D forever?

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

I mean, isn't the C-Style declaration syntax considered to be a design 
flaw in the original C? If so, does D really need to carry it out in 
order to attract C/C++ people?
That seems to be (to me) totally against the philosophy of D.

So Walter, I would like to please hear your opinion/decision about 
C-Style declarations; are they here to stay? or will they be deprecated 
at some point?
Mar 31 2006
next sibling parent BCS <BCS_member pathlink.com> writes:
Hasan Aljudy wrote:
 << I don't know if this has been discussed before, but I don't remember 
 seeing any discussion about it. If it has been, please direct me to one 
 of the old threads that discussed it. >>
 
 I noticed that D supports the klumsy C-Style declarations, like
 
 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!!
 
 D has nicer syntax,
 int[3]*[5] x;    // x is an array of 5 pointers to arrays of 3 ints
 

 
 Since D has a more intelligent way of declaring the same things, the 
 C-Style syntax is unnecessarily redundant IMHO.
 
 My understanding is that it's supported to attract the C/C++ people and 
 get them familiarized with D quickly.
 
 But, does this mean that C-Style declarations are gonna stay with D 
 forever?
 
 I personally would like to see them gone. but that's not for me to decide.

 So Walter, I would like to please hear your opinion/decision about 
 C-Style declarations; are they here to stay? or will they be deprecated 
 at some point?
 
 

solution would be a type translator tool. Give it a listing of types in C and it gives you the same type in D (and vise versa). I would like to see them go also.
Mar 31 2006
prev sibling next sibling parent reply Tom <ihate spam.com> writes:
Hasan Aljudy escribió:
 << I don't know if this has been discussed before, but I don't remember 
 seeing any discussion about it. If it has been, please direct me to one 
 [snip]

I do understand C style declarations now but *only* through years of awful experiences and they are abominable. So I'll have to agree 100% with its removal if it were my decision. I'm C/C++ programmer and I didn't need that to get attracted to D, in fact, on the contrary its clearer syntax is one of the most attractive points. I'd stay with C++ if D had the same ugly syntax (as flat as it sounds). -- Tom;
Mar 31 2006
parent Frank Benoit <frank nix.de> writes:
I vote for this too.
Mar 31 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Hasan Aljudy wrote:
 
 So Walter, I would like to please hear your opinion/decision about 
 C-Style declarations; are they here to stay? or will they be deprecated 
 at some point?

I'm hoping they will be deprecated before 1.0. While this may mean a small amount of extra work porting headers, I think it's worthwhile. Sean
Mar 31 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:
 Hasan Aljudy wrote:
 So Walter, I would like to please hear your opinion/decision about 
 C-Style declarations; are they here to stay? or will they be 
 deprecated at some point?

I'm hoping they will be deprecated before 1.0. While this may mean a small amount of extra work porting headers, I think it's worthwhile.

I left them in because they do not cause any ambiguities or trouble with the D declaration syntax. It also significantly reduces the amount of work needed to translate code to D. I don't see a compelling reason to remove them; just don't use them if you don't like them.
Mar 31 2006
next sibling parent reply BCS <BCS_member pathlink.com> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 
 Hasan Aljudy wrote:

 So Walter, I would like to please hear your opinion/decision about 
 C-Style declarations; are they here to stay? or will they be 
 deprecated at some point?

I'm hoping they will be deprecated before 1.0. While this may mean a small amount of extra work porting headers, I think it's worthwhile.

I left them in because they do not cause any ambiguities or trouble with the D declaration syntax. It also significantly reduces the amount of work needed to translate code to D. I don't see a compelling reason to remove them; just don't use them if you don't like them.

http://www.digitalmars.com/d/faq.html#q3 from http://www.digitalmars.com/d/overview.html "Major Goals of D [...] * Make D substantially easier to implement a compiler for than C++." If people don't want it, then it just adds unnecessarily to the task of making a compiler.
Mar 31 2006
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
BCS wrote:
 Walter Bright wrote:
 Sean Kelly wrote:
 Hasan Aljudy wrote:
 
 So Walter, I would like to please hear your opinion/decision
 about C-Style declarations; are they here to stay? or will they
 be deprecated at some point?

I'm hoping they will be deprecated before 1.0. While this may mean a small amount of extra work porting headers, I think it's worthwhile.

I left them in because they do not cause any ambiguities or trouble with the D declaration syntax. It also significantly reduces the amount of work needed to translate code to D. I don't see a compelling reason to remove them; just don't use them if you don't like them.

http://www.digitalmars.com/d/faq.html#q3 from http://www.digitalmars.com/d/overview.html "Major Goals of D [...] * Make D substantially easier to implement a compiler for than C++." If people don't want it, then it just adds unnecessarily to the task of making a compiler.

Count me in for the removal. (I do know "some" people find them handy, but this particular detail does not stand in line with other D differences from C/C++ of lesser visibility.)
Mar 31 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
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.
Mar 31 2006
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 
 Hasan Aljudy wrote:

 So Walter, I would like to please hear your opinion/decision about 
 C-Style declarations; are they here to stay? or will they be 
 deprecated at some point?

I'm hoping they will be deprecated before 1.0. While this may mean a small amount of extra work porting headers, I think it's worthwhile.

I left them in because they do not cause any ambiguities or trouble with the D declaration syntax. It also significantly reduces the amount of work needed to translate code to D. I don't see a compelling reason to remove them; just don't use them if you don't like them.

I think it kinda does. in C/C++, the following is valid declarations: typedef int foo; int(x); //OK, declares x as int foo(y); //OK, declares y as foo in D, we get this: alias int bar; typedef int foo; int(x); // OK, declares x as int foo(y); // OK!! bar(z); // OK!! int main() { .y = 10; // ok .z = 20; // ok int(x); // OK, declares x as int foo(y); // Error!! bar(z); // Error!! return 0; } why is foo(y) allowed at the global scope? and why is it disallowed at local scope?!!
Mar 31 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Mar 31 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.

I /think/ this comes from the C-Style declaration syntax .. Decl: BasicType Declarators ; Declarator: Identifier ( Declarator ) hence, int(x) has a parse tree which looks like: Decl | _____|_______ | | BaiscType Declarator | | int ____|_______ | | | | | | ( Declarator ) | | Identifier | | x The C-Style declaration syntax requires parenthesis around declarators, D-Style declaration syntax does not. I think this is caught at the local scope because there's an ambiguity, is # foo(x) a function call or a declaration? At the global scope there's no ambiguity, it must be a declaration. However, inside function bodies, it could be a statement (function call or other things). The code that disambiguates /assumes/ that foo(bar) declarations are not allowed, but the grammar allows it, and the docs don't indicate anywhere that foo(bar) is not a valid declaration. Hence, C-Style declarations cause ambiguities and trouble with the D declaration syntax. Can they be gone now? :)
Mar 31 2006
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
Apr 03 2006
parent Walter Bright <newshound digitalmars.com> writes:
Hasan Aljudy wrote:
 ok, here's another corner case.
 
 Should
 foo(*bar)
 be allowed as a declaration?

No.
Apr 03 2006
prev sibling next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Hasan Aljudy escribió:
 << I don't know if this has been discussed before, but I don't remember 
 seeing any discussion about it. If it has been, please direct me to one 
 of the old threads that discussed it. >>
 
 I noticed that D supports the klumsy C-Style declarations, like
 
 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!!
 
 D has nicer syntax,
 int[3]*[5] x;    // x is an array of 5 pointers to arrays of 3 ints
 
 I can't say I understand how it works, but when I read the description, 
 is makes a lot of sense. It reads right to left:
 [5]    array of size 5
 *      pointer(s)
 [3]    array of size 3
 int    int(s)
 
 array of 5 pointers to array of 3 ints!
 
 The only reason I don't understand it right away is because I don't like 
 nested complex declarations like this anyway, so I never tried to learn 
 how to declare them. However, the D syntax makes alot of sense.
 
 Consider for example this C-Style declaration:
 int (*x)(char);
 
 VS this D-Style declaration:
 int function(char) x;
 
 Why does D support int (*x)(char); anyway?!
 
 Since D has a more intelligent way of declaring the same things, the 
 C-Style syntax is unnecessarily redundant IMHO.
 
 My understanding is that it's supported to attract the C/C++ people and 
 get them familiarized with D quickly.
 
 But, does this mean that C-Style declarations are gonna stay with D 
 forever?
 
 I personally would like to see them gone. but that's not for me to decide.
 
 I mean, isn't the C-Style declaration syntax considered to be a design 
 flaw in the original C? If so, does D really need to carry it out in 
 order to attract C/C++ people?
 That seems to be (to me) totally against the philosophy of D.
 
 So Walter, I would like to please hear your opinion/decision about 
 C-Style declarations; are they here to stay? or will they be deprecated 
 at some point?
 

Funny, I was thinking the exact same thing today, but I decided not to write about it because I understand they're there to ease porting. However, I think they should go, and as others think the same way, how about a plan to kiss them good bye? What if it was clearly stated in the D docs something like "C style declarations will be deprecated in 2.0 and completely gone in 3.0"? -- Carlos Santander Bernal
Mar 31 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Carlos Santander wrote:

 Hasan Aljudy escribió:
 << I don't know if this has been discussed before, but I don't remember
 seeing any discussion about it. If it has been, please direct me to one
 of the old threads that discussed it. >>
 
 I noticed that D supports the klumsy C-Style declarations, like
 
 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!!
 
 D has nicer syntax,
 int[3]*[5] x;    // x is an array of 5 pointers to arrays of 3 ints
 
 I can't say I understand how it works, but when I read the description,
 is makes a lot of sense. It reads right to left:
 [5]    array of size 5
 *      pointer(s)
 [3]    array of size 3
 int    int(s)
 
 array of 5 pointers to array of 3 ints!
 
 The only reason I don't understand it right away is because I don't like
 nested complex declarations like this anyway, so I never tried to learn
 how to declare them. However, the D syntax makes alot of sense.
 
 Consider for example this C-Style declaration:
 int (*x)(char);
 
 VS this D-Style declaration:
 int function(char) x;
 
 Why does D support int (*x)(char); anyway?!
 
 Since D has a more intelligent way of declaring the same things, the
 C-Style syntax is unnecessarily redundant IMHO.
 
 My understanding is that it's supported to attract the C/C++ people and
 get them familiarized with D quickly.
 
 But, does this mean that C-Style declarations are gonna stay with D
 forever?
 
 I personally would like to see them gone. but that's not for me to
 decide.
 
 I mean, isn't the C-Style declaration syntax considered to be a design
 flaw in the original C? If so, does D really need to carry it out in
 order to attract C/C++ people?
 That seems to be (to me) totally against the philosophy of D.
 
 So Walter, I would like to please hear your opinion/decision about
 C-Style declarations; are they here to stay? or will they be deprecated
 at some point?
 

Funny, I was thinking the exact same thing today, but I decided not to write about it because I understand they're there to ease porting. However, I think they should go, and as others think the same way, how about a plan to kiss them good bye? What if it was clearly stated in the D docs something like "C style declarations will be deprecated in 2.0 and completely gone in 3.0"?

No reason to keep them around that long, IMHO. :)
Apr 01 2006
parent reply Carlos Santander <csantander619 gmail.com> writes:
Lars Ivar Igesund escribió:
 Carlos Santander wrote:
 However, I think they should go, and as others think the same way, how
 about a plan to kiss them good bye? What if it was clearly stated in the D
 docs something like "C style declarations will be deprecated in 2.0 and
 completely gone in 3.0"?

No reason to keep them around that long, IMHO. :)

My rationale is that D will need more code to be ported during that time and allowing C style declarations will help that. However, as more and more D code is written, the need for porting will fade. I don't know how clear I was because I don't know what else to say but I feel it's incomplete. -- Carlos Santander Bernal
Apr 01 2006
parent reply AgentOrange <AgentOrange_member pathlink.com> writes:
In article <e0m3q5$30sh$1 digitaldaemon.com>, Carlos Santander says...
Lars Ivar Igesund escribió:
 Carlos Santander wrote:
 However, I think they should go, and as others think the same way, how
 about a plan to kiss them good bye? What if it was clearly stated in the D
 docs something like "C style declarations will be deprecated in 2.0 and
 completely gone in 3.0"?

No reason to keep them around that long, IMHO. :)

My rationale is that D will need more code to be ported during that time and allowing C style declarations will help that. However, as more and more D code is written, the need for porting will fade. I don't know how clear I was because I don't know what else to say but I feel it's incomplete. -- Carlos Santander Bernal

yeah, we want to break a whole bunch of code because someone doesnt quite understand c style declarations? is this a joke?
Apr 01 2006
next sibling parent Carlos Santander <csantander619 gmail.com> writes:
AgentOrange escribió:
 In article <e0m3q5$30sh$1 digitaldaemon.com>, Carlos Santander says...
 Lars Ivar Igesund escribió:
 Carlos Santander wrote:
 However, I think they should go, and as others think the same way, how
 about a plan to kiss them good bye? What if it was clearly stated in the D
 docs something like "C style declarations will be deprecated in 2.0 and
 completely gone in 3.0"?


allowing C style declarations will help that. However, as more and more D code is written, the need for porting will fade. I don't know how clear I was because I don't know what else to say but I feel it's incomplete. -- Carlos Santander Bernal

yeah, we want to break a whole bunch of code because someone doesnt quite understand c style declarations? is this a joke?

No, it's not. I'm sorry if you don't like my idea, you just had to say that. Gee... -- Carlos Santander Bernal
Apr 01 2006
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
AgentOrange wrote:

 In article <e0m3q5$30sh$1 digitaldaemon.com>, Carlos Santander says...
Lars Ivar Igesund escribió:
 Carlos Santander wrote:
 However, I think they should go, and as others think the same way, how
 about a plan to kiss them good bye? What if it was clearly stated in
 the D docs something like "C style declarations will be deprecated in
 2.0 and completely gone in 3.0"?

No reason to keep them around that long, IMHO. :)

My rationale is that D will need more code to be ported during that time and allowing C style declarations will help that. However, as more and more D code is written, the need for porting will fade. I don't know how clear I was because I don't know what else to say but I feel it's incomplete. -- Carlos Santander Bernal

yeah, we want to break a whole bunch of code because someone doesnt quite understand c style declarations? is this a joke?

No joke, agent. Although I do agree (after actually thinking about it) that the syntax should go through deprecation before being removed. I can barely see the usefulness in porting, but keeping this code around for any length, will most likely lead to maintainance problems in the long run when the C legacy is of less use in the D community. I think the conversion from C-style to D-style should be made by those initially porting from C, not those coming after who most likely have less of a C background. Making the feature deprecated force the coder to think about it.
Apr 01 2006
parent reply Sebastián E. Peyrott <as7cf yahoo.com> writes:
In article <e0mj1h$fct$1 digitaldaemon.com>, Lars Ivar Igesund says...
AgentOrange wrote:

 In article <e0m3q5$30sh$1 digitaldaemon.com>, Carlos Santander says...
Lars Ivar Igesund escribió:
 Carlos Santander wrote:
 However, I think they should go, and as others think the same way, how
 about a plan to kiss them good bye? What if it was clearly stated in
 the D docs something like "C style declarations will be deprecated in
 2.0 and completely gone in 3.0"?

No reason to keep them around that long, IMHO. :)

My rationale is that D will need more code to be ported during that time and allowing C style declarations will help that. However, as more and more D code is written, the need for porting will fade. I don't know how clear I was because I don't know what else to say but I feel it's incomplete. -- Carlos Santander Bernal

yeah, we want to break a whole bunch of code because someone doesnt quite understand c style declarations? is this a joke?

No joke, agent. Although I do agree (after actually thinking about it) that the syntax should go through deprecation before being removed. I can barely see the usefulness in porting, but keeping this code around for any length, will most likely lead to maintainance problems in the long run when the C legacy is of less use in the D community. I think the conversion from C-style to D-style should be made by those initially porting from C, not those coming after who most likely have less of a C background. Making the feature deprecated force the coder to think about it.

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.
Apr 01 2006
parent BCS <BCS_member pathlink.com> writes:
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
Apr 01 2006
prev sibling parent Tom <ihate spam.com> writes:
Carlos Santander escribió:
 Hasan Aljudy escribió:
 << I don't know if this has been discussed before, but I don't 
 remember seeing any discussion about it. If it has been, please direct 
 me to one of the old threads that discussed it. >>

 I noticed that D supports the klumsy C-Style declarations, like

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

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

 I can't say I understand how it works, but when I read the 
 description, is makes a lot of sense. It reads right to left:
 [5]    array of size 5
 *      pointer(s)
 [3]    array of size 3
 int    int(s)

 array of 5 pointers to array of 3 ints!

 The only reason I don't understand it right away is because I don't 
 like nested complex declarations like this anyway, so I never tried to 
 learn how to declare them. However, the D syntax makes alot of sense.

 Consider for example this C-Style declaration:
 int (*x)(char);

 VS this D-Style declaration:
 int function(char) x;

 Why does D support int (*x)(char); anyway?!

 Since D has a more intelligent way of declaring the same things, the 
 C-Style syntax is unnecessarily redundant IMHO.

 My understanding is that it's supported to attract the C/C++ people 
 and get them familiarized with D quickly.

 But, does this mean that C-Style declarations are gonna stay with D 
 forever?

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

 I mean, isn't the C-Style declaration syntax considered to be a design 
 flaw in the original C? If so, does D really need to carry it out in 
 order to attract C/C++ people?
 That seems to be (to me) totally against the philosophy of D.

 So Walter, I would like to please hear your opinion/decision about 
 C-Style declarations; are they here to stay? or will they be 
 deprecated at some point?

Funny, I was thinking the exact same thing today, but I decided not to write about it because I understand they're there to ease porting. However, I think they should go, and as others think the same way, how about a plan to kiss them good bye? What if it was clearly stated in the D docs something like "C style declarations will be deprecated in 2.0 and completely gone in 3.0"?

OMG! No, just drop them now! :) -- Tom;
Apr 01 2006
prev sibling parent Miles <_______ _______.____> writes:
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.
Apr 02 2006