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?
 
 


IIRC the c style types are for convenience when porting from C. I think a
better 
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

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"?


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