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.

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? :)

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

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. :)

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;

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

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?

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

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.

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.