www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Deprecate C style declerations?

reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Should we do this?  As in cause:

# int foo[];
# int bar*;

And others to issue deprecation errors.  I think it would be a good idea, and
shouldn't 
break extern(C) declarations, so long as one doesn't try to mix types.  (I
don't think we 
can mix them in the C way at all, anyhow.  Haven't tried, though.)  Or else
change the 
rules such that array/pointer decoration applies to the variable and not the
type -- and 
correct me if I'm wrong about this not being the current behavior.

# int num   ,
#     arr[] ,
#     ptr*  ;

vs

# int   num ;
# int[] arr ;
# int*  ptr ;

-- Chris Nicholson-Sauls
Dec 20 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
news:emcekr$2sah$1 digitaldaemon.com...
 Should we do this?  As in cause:

 # int foo[];
 # int bar*;

 And others to issue deprecation errors.  I think it would be a good idea, 
 and shouldn't break extern(C) declarations, so long as one doesn't try to 
 mix types.  (I don't think we can mix them in the C way at all, anyhow. 
 Haven't tried, though.)

I agree, though int bar*; isn't legal any way you slice it, D or C. I'd also be interested in phasing out the C-style function pointer syntax: int (*foo)(int, int); => int function(int, int) foo;
 Or else change the rules such that array/pointer decoration applies to the 
 variable and not the type -- and correct me if I'm wrong about this not 
 being the current behavior.

 # int num   ,
 #     arr[] ,
 #     ptr*  ;

 vs

 # int   num ;
 # int[] arr ;
 # int*  ptr ;

I think that C "feature" was dropped in D because it makes multiple declarations harder to read.
Dec 20 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
 news:emcekr$2sah$1 digitaldaemon.com...
 Should we do this?  As in cause:

 # int foo[];
 # int bar*;

 And others to issue deprecation errors.  I think it would be a good idea, 
 and shouldn't break extern(C) declarations, so long as one doesn't try to 
 mix types.  (I don't think we can mix them in the C way at all, anyhow. 
 Haven't tried, though.)

I agree, though

The syntax of static multidimensional arrays is better using C-style I think: int[2][3][4] a; // means a[3][2][1] is max legal index int a[2][3][4]; // means a[1][2][3] is max legal index I hope D gets real multidimensonal arrays eventually though. Then the need for all those brackets will go away and you'll just have: int[2,3,4] a; In the mean time I've just started www.dsource.org/projects/multiarray to which I will soon upload the ndarray code I've been working on. --bb
Dec 20 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:emcjig$30qo$1 digitaldaemon.com...
 The syntax of static multidimensional arrays is better using C-style I 
 think:

 int[2][3][4] a; //  means a[3][2][1] is max legal index

 int a[2][3][4]; //  means a[1][2][3] is max legal index

That's true. In fact, I think there's a flag in the DMD frontend to make it so that the D-style int[2][3][4] a; would have a max index of [1][2][3]. But that goes against the right-to-left rule of declarations..
 I hope D gets real multidimensonal arrays eventually though.  Then the 
 need for all those brackets will go away and you'll just have:

    int[2,3,4] a;

Though they are two different concepts. If you need a contiguous block of memory which can be accessed with more than one dimension, then a rectangular array is just what you need. But for most other applications, arrays of arrays are fine, and resizing rectangular arrays is kind of a pain so..
Dec 20 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:emcjig$30qo$1 digitaldaemon.com...
 The syntax of static multidimensional arrays is better using C-style I 
 think:

 int[2][3][4] a; //  means a[3][2][1] is max legal index

 int a[2][3][4]; //  means a[1][2][3] is max legal index

That's true. In fact, I think there's a flag in the DMD frontend to make it so that the D-style int[2][3][4] a; would have a max index of [1][2][3]. But that goes against the right-to-left rule of declarations..

Yeh, that's not a good enough reason to break the nice strict right-to-left consistency D has now. But I think it may be a good enough reason to leave in the "int a[2][3][4]" syntax.
 I hope D gets real multidimensonal arrays eventually though.  Then the 
 need for all those brackets will go away and you'll just have:

    int[2,3,4] a;

Though they are two different concepts.

Yep, different. I shouldn't have said "all" of them would go away. I was thinking "many of them". But maybe even then I was overestimating. --bb
Dec 20 2006
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Jarrett Billingsley wrote:
 "Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
 news:emcekr$2sah$1 digitaldaemon.com...
 
Should we do this?  As in cause:

# int foo[];
# int bar*;

And others to issue deprecation errors.  I think it would be a good idea, 
and shouldn't break extern(C) declarations, so long as one doesn't try to 
mix types.  (I don't think we can mix them in the C way at all, anyhow. 
Haven't tried, though.)

I agree, though int bar*; isn't legal any way you slice it, D or C. I'd also be interested in phasing out the C-style function pointer syntax: int (*foo)(int, int); => int function(int, int) foo;
Or else change the rules such that array/pointer decoration applies to the 
variable and not the type -- and correct me if I'm wrong about this not 
being the current behavior.

# int num   ,
#     arr[] ,
#     ptr*  ;

vs

# int   num ;
# int[] arr ;
# int*  ptr ;

I think that C "feature" was dropped in D because it makes multiple declarations harder to read.

Hear-hear! No need for C's crummy array syntax. Writing support for outputting the right C types in bcd.gen was a huge PITA because of it X_X Hear-hear particularly to deprecating the C function syntax. That syntax makes me want to gag myself with a spoon. - Gregor Richards
Dec 20 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Gregor Richards wrote:
 Jarrett Billingsley wrote:
 "Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
 news:emcekr$2sah$1 digitaldaemon.com...

 Should we do this?  As in cause:

 # int foo[];
 # int bar*;

 And others to issue deprecation errors.  I think it would be a good 
 idea, and shouldn't break extern(C) declarations, so long as one 
 doesn't try to mix types.  (I don't think we can mix them in the C 
 way at all, anyhow. Haven't tried, though.)

I agree, though int bar*; isn't legal any way you slice it, D or C. I'd also be interested in phasing out the C-style function pointer syntax: int (*foo)(int, int); => int function(int, int) foo;
 Or else change the rules such that array/pointer decoration applies 
 to the variable and not the type -- and correct me if I'm wrong about 
 this not being the current behavior.

 # int num   ,
 #     arr[] ,
 #     ptr*  ;

 vs

 # int   num ;
 # int[] arr ;
 # int*  ptr ;

I think that C "feature" was dropped in D because it makes multiple declarations harder to read.

Hear-hear! No need for C's crummy array syntax. Writing support for outputting the right C types in bcd.gen was a huge PITA because of it X_X Hear-hear particularly to deprecating the C function syntax. That syntax makes me want to gag myself with a spoon. - Gregor Richards

Hear hear ..! I know how you feel!! I tried to open this subject before, but didn't get anywhere ..
Dec 20 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Hasan Aljudy wrote:
 
 
 Gregor Richards wrote:
 Jarrett Billingsley wrote:
 "Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
 news:emcekr$2sah$1 digitaldaemon.com...

 Should we do this?  As in cause:

 # int foo[];
 # int bar*;

 And others to issue deprecation errors.  I think it would be a good 
 idea, and shouldn't break extern(C) declarations, so long as one 
 doesn't try to mix types.  (I don't think we can mix them in the C 
 way at all, anyhow. Haven't tried, though.)

I agree, though int bar*; isn't legal any way you slice it, D or C. I'd also be interested in phasing out the C-style function pointer syntax: int (*foo)(int, int); => int function(int, int) foo;
 Or else change the rules such that array/pointer decoration applies 
 to the variable and not the type -- and correct me if I'm wrong 
 about this not being the current behavior.

 # int num   ,
 #     arr[] ,
 #     ptr*  ;

 vs

 # int   num ;
 # int[] arr ;
 # int*  ptr ;

I think that C "feature" was dropped in D because it makes multiple declarations harder to read.

Hear-hear! No need for C's crummy array syntax. Writing support for outputting the right C types in bcd.gen was a huge PITA because of it X_X Hear-hear particularly to deprecating the C function syntax. That syntax makes me want to gag myself with a spoon. - Gregor Richards

Hear hear ..! I know how you feel!! I tried to open this subject before, but didn't get anywhere ..

I agree, too -- the main reason for retaining it was to simplify conversion from C code to D, but (a) we now have ctod, so it can be automated in most cases; (b) in my experience (eg manually translating the Windows headers), it's trivial to translate anyway, and it gives significant benefits to clarity. The really weird thing about the C syntax is that you can define a *function type* (not just function pointers). There's no D equivalent to that, although I'm not aware of any uses of the construct. We're building up a list of features that should be deprecated: * 'length' inside slices. * C function syntax * C declaration syntax in general I'd also add: * some alternative to #line that doesn't waste the '#' symbol on such a rarely-used feature. And there are probably a few more I've forgotten about.
Dec 21 2006
next sibling parent nazo <lovesyao gmail.com> writes:
Don Clugston wrote:
 I'd also add:
 * some alternative to #line that doesn't waste the '#' symbol on such a 
 rarely-used feature.

//LINE: 12 //TODO: add more features //FIXME: this list is broken
Dec 21 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Don Clugston wrote:
 Hasan Aljudy wrote:
 Gregor Richards wrote:
 Jarrett Billingsley wrote:
 "Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
 news:emcekr$2sah$1 digitaldaemon.com...

 Should we do this?  As in cause:

 # int foo[];
 # int bar*;

 And others to issue deprecation errors.  I think it would be a good 
 idea, and shouldn't break extern(C) declarations, so long as one 
 doesn't try to mix types.  (I don't think we can mix them in the C 
 way at all, anyhow. Haven't tried, though.)

I agree, though int bar*; isn't legal any way you slice it, D or C. I'd also be interested in phasing out the C-style function pointer syntax: int (*foo)(int, int); => int function(int, int) foo;
 Or else change the rules such that array/pointer decoration applies 
 to the variable and not the type -- and correct me if I'm wrong 
 about this not being the current behavior.

 # int num   ,
 #     arr[] ,
 #     ptr*  ;

 vs

 # int   num ;
 # int[] arr ;
 # int*  ptr ;

I think that C "feature" was dropped in D because it makes multiple declarations harder to read.

Hear-hear! No need for C's crummy array syntax. Writing support for outputting the right C types in bcd.gen was a huge PITA because of it X_X Hear-hear particularly to deprecating the C function syntax. That syntax makes me want to gag myself with a spoon. - Gregor Richards

Hear hear ..! I know how you feel!! I tried to open this subject before, but didn't get anywhere ..

I agree, too -- the main reason for retaining it was to simplify conversion from C code to D, but (a) we now have ctod, so it can be automated in most cases; (b) in my experience (eg manually translating the Windows headers), it's trivial to translate anyway, and it gives significant benefits to clarity. The really weird thing about the C syntax is that you can define a *function type* (not just function pointers). There's no D equivalent to that, although I'm not aware of any uses of the construct. We're building up a list of features that should be deprecated: * 'length' inside slices. * C function syntax * C declaration syntax in general

Let's hope Walter hears this before the dead line for v1.0 btw, what do you mean by "C function syntax"?
 
 I'd also add:
 * some alternative to #line that doesn't waste the '#' symbol on such a 
 rarely-used feature.
 

I've always wondered if there's even anyone out there using this so called "feature"? Why would you want to alter the lexer's internal state of the current line number? Who even came up with the idea?
 And there are probably a few more I've forgotten about.

Dec 21 2006
next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Hasan Aljudy wrote:
 
 
 Don Clugston wrote:

 I'd also add:
 * some alternative to #line that doesn't waste the '#' symbol on such 
 a rarely-used feature.


I kind of like Nazo's suggestion of putting it in a comment. Any un-aware parser would automatically just ignore such things. /// LINE: 17 Otherwise, could something like pragma(line,17) work?
 I've always wondered if there's even anyone out there using this so 
 called "feature"?
 Why would you want to alter the lexer's internal state of the current 
 line number?
 Who even came up with the idea?

It is useful when the code is auto generated, having line numbers referring back to the original file. One example would be a YACC generated parser with line numbers in the generated code referring to the parser definition file. /Oskar
Dec 21 2006
prev sibling parent reply Daniel Keep <daniel.keep+lists gmail.com> writes:
Hasan Aljudy wrote:
 
 
 Don Clugston wrote:
 I'd also add:
 * some alternative to #line that doesn't waste the '#' symbol on such 
 a rarely-used feature.

I've always wondered if there's even anyone out there using this so called "feature"? Why would you want to alter the lexer's internal state of the current line number? Who even came up with the idea?
 And there are probably a few more I've forgotten about.


I use it! I'm currently working on a project that my supervisor wanted written in literate style. So I ported CWEB over to D, and it relies heavily on the use of #line. Basically, where code appears in the source document, and where it appears in the generated code often have little correlation, and without #line debugging would be next to impossible. Remember, just because you don't use a feature and think it's ugly, doesn't mean no one does. Let me put it this way: if #line is removed, I have to go back to C since I doubt my supervisor will let me use a language for which I'm stuck using an old compiler for. Hell, *I* wouldn't want to do that. (As for C-style declarations, it means you can copy+paste a whole bunch of C declarations into D source. Yes they can be converted, but this is as simple as it gets. If it's no extra work for Walter, why remove it?) -- Daniel "you'll pry #line from my cold, dead hands"
Dec 23 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Daniel Keep wrote:
 Hasan Aljudy wrote:
 Don Clugston wrote:
 I'd also add:
 * some alternative to #line that doesn't waste the '#' symbol on such 
 a rarely-used feature.

I've always wondered if there's even anyone out there using this so called "feature"? Why would you want to alter the lexer's internal state of the current line number? Who even came up with the idea?
 And there are probably a few more I've forgotten about.


I use it! I'm currently working on a project that my supervisor wanted written in literate style. So I ported CWEB over to D, and it relies heavily on the use of #line. Basically, where code appears in the source document, and where it appears in the generated code often have little correlation, and without #line debugging would be next to impossible. Remember, just because you don't use a feature and think it's ugly, doesn't mean no one does. Let me put it this way: if #line is removed, I have to go back to C since I doubt my supervisor will let me use a language for which I'm stuck using an old compiler for. Hell, *I* wouldn't want to do that.

It's not about #line, just about the use of '#' for that single syntax situation. (Even the suggested ##line would probably be acceptable).
 (As for C-style declarations, it means you can copy+paste a whole bunch 
 of C declarations into D source.  Yes they can be converted, but this is 
 as simple as it gets.  If it's no extra work for Walter, why remove it?)

Really, you can't just copy and paste. You need to change typedef to alias, you need to change enums, etc. It is just supporting a bad habit. Reasons to remove it: * Makes code harder to read -- it is currently possible to mix C-style and D style declarations in a single block of code. That's disgusting. * Complicates the compiler, and means that any D parsing tool also has to parse C declarations. * Probably restricts future language options, because of ambiguities that it introduces.
     -- Daniel "you'll pry #line from my cold, dead hands"

Dec 23 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Don Clugston wrote:

 Daniel Keep wrote:
 
 (As for C-style declarations, it means you can copy+paste a whole bunch
 of C declarations into D source.  Yes they can be converted, but this is
 as simple as it gets.  If it's no extra work for Walter, why remove it?)

Really, you can't just copy and paste. You need to change typedef to alias, you need to change enums, etc. It is just supporting a bad habit. Reasons to remove it: * Makes code harder to read -- it is currently possible to mix C-style and D style declarations in a single block of code. That's disgusting. * Complicates the compiler, and means that any D parsing tool also has to parse C declarations. * Probably restricts future language options, because of ambiguities that it introduces.

Yes, I believe this has been discussed before, although at greater lengths. I can't remember that there has been any particularly convincing arguments in the past, and the only reason I can think of, is for C source conversion easiness. I think it is a bad reason. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Dec 29 2006
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Don Clugston schrieb am 2006-12-21:

<snip>

 We're building up a list of features that should be deprecated:
 * 'length' inside slices.
 * C function syntax
 * C declaration syntax in general

 I'd also add:
 * some alternative to #line that doesn't waste the '#' symbol on such a 
 rarely-used feature.

How about "pragma(line, ...);" ? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFimaKLK5blCcjpWoRAkZCAJwNKgfp5xXjFLV/yZowJo2okfcqrgCdF6HE EQsn2hTuI7xrgGapSL48Xsc= =cOgp -----END PGP SIGNATURE-----
Dec 21 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message 
news:slrneokpko.mj5.thomas-dloop birke.kuehne.cn...

 How about "pragma(line, ...);" ?

Much nicer looking, but unfortunately, there's a problem with it. Pragmas are not considered until after the lexical pass, and that's what the #line directive affects. Basically the lexer would have to know about pragmas and be able to syntax and semantic them partially, breaking the separation between the passes. The current syntax has the advantage of meaning absolutely nothing after the lexical pass completes. Furthermore, pragmas can only legally appear where declarations would. #line can appear anywhere, even in the middle of a line. But I agree that it's a waste of # :)
Dec 21 2006
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jarrett Billingsley wrote:
 "Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message 
 news:slrneokpko.mj5.thomas-dloop birke.kuehne.cn...
 
 How about "pragma(line, ...);" ?

Much nicer looking, but unfortunately, there's a problem with it. Pragmas are not considered until after the lexical pass, and that's what the #line directive affects. Basically the lexer would have to know about pragmas and be able to syntax and semantic them partially, breaking the separation between the passes. The current syntax has the advantage of meaning absolutely nothing after the lexical pass completes. Furthermore, pragmas can only legally appear where declarations would. #line can appear anywhere, even in the middle of a line. But I agree that it's a waste of # :)

It is a waste. So pragma's doen't work. I also hesitate to make some notation in a comment suddenly have some effect. Maybe just make the sigil be sequence of symbols rather than a single one? :#line 6 "foo\bar" /#line 6 "fool\bar" ##line 6 "foo\bar" ##{{line 6 "foo\bar"}} ##/line Or what about #pragma(line, ...) --bb
Dec 22 2006
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Baxter schrieb am 2006-12-22:
 Jarrett Billingsley wrote:
 "Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message 
 news:slrneokpko.mj5.thomas-dloop birke.kuehne.cn...
 
 How about "pragma(line, ...);" ?

Much nicer looking, but unfortunately, there's a problem with it. Pragmas are not considered until after the lexical pass, and that's what the #line directive affects. Basically the lexer would have to know about pragmas and be able to syntax and semantic them partially, breaking the separation between the passes. The current syntax has the advantage of meaning absolutely nothing after the lexical pass completes. Furthermore, pragmas can only legally appear where declarations would. #line can appear anywhere, even in the middle of a line. But I agree that it's a waste of # :)


 It is a waste.  So pragma's doen't work.  I also hesitate to make some 
 notation in a comment suddenly have some effect.  Maybe just make the 
 sigil be sequence of symbols rather than a single one?

Does anyone actually use the #line construct? Thomas -----BEGIN PGP SIGNATURE----- iD4DBQFFiwYYLK5blCcjpWoRAg7gAJjTKNKjOSh9xogaJMrcG96//kV/AJ9ZVTCM POsdbNOIJci9yBmgja/7vA== =3IuB -----END PGP SIGNATURE-----
Dec 21 2006
parent Pragma <ericanderton yahoo.removeme.com> writes:
Thomas Kuehne wrote:
 
 Does anyone actually use the #line construct?

YES! It's extremely handy whenever you're writing something that's generating D code, especially when you allow chunks of D code through to the output. For example, I used it extensively while researching for DSP, and I plan on using it for Enki's codegen (when I get around to it). A more concrete, if not contrived, example would be a PHP-style (pre)processor for D: <html><body> <? int value = toInt(url["value"]); auto result = Fibonacci(value); ?> The Fibonacci sequence for <?=value?> is <?=result?> </body></html> This would emit code (presumably to be run like an applet), like so: // output.d echo("<html><body> "); #line 3 source.dhp int value = toInt(url["value"]); auto result = Fibonacci(value); echo("The Fibonacci sequence for "); #line 5 source.dhp echo(value); echo(" is "); #line 5 source.dhp echo(result); echo(" </body></html>"); This way, any errors in the <??> expressions can be tied back to the original source, should there be a compiler error. -- - EricAnderton at yahoo
Dec 21 2006
prev sibling parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:
 ##line 6 "foo\bar"

Oh, now I like that. Change it to this, and we can introduce # as a regular token. -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Dec 21 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don Clugston wrote:
 Hasan Aljudy wrote:
 Gregor Richards wrote:
 Jarrett Billingsley wrote:
 "Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
 news:emcekr$2sah$1 digitaldaemon.com...

 Should we do this?  As in cause:

 # int foo[];
 # int bar*;

 And others to issue deprecation errors.  I think it would be a good 
 idea, and shouldn't break extern(C) declarations, so long as one 
 doesn't try to mix types.  (I don't think we can mix them in the C 
 way at all, anyhow. Haven't tried, though.)

I agree, though int bar*; isn't legal any way you slice it, D or C. I'd also be interested in phasing out the C-style function pointer syntax: int (*foo)(int, int); => int function(int, int) foo;
 Or else change the rules such that array/pointer decoration applies 
 to the variable and not the type -- and correct me if I'm wrong 
 about this not being the current behavior.

 # int num   ,
 #     arr[] ,
 #     ptr*  ;

 vs

 # int   num ;
 # int[] arr ;
 # int*  ptr ;

I think that C "feature" was dropped in D because it makes multiple declarations harder to read.

Hear-hear! No need for C's crummy array syntax. Writing support for outputting the right C types in bcd.gen was a huge PITA because of it X_X Hear-hear particularly to deprecating the C function syntax. That syntax makes me want to gag myself with a spoon. - Gregor Richards

Hear hear ..! I know how you feel!! I tried to open this subject before, but didn't get anywhere ..

I agree, too -- the main reason for retaining it was to simplify conversion from C code to D, but (a) we now have ctod, so it can be automated in most cases; (b) in my experience (eg manually translating the Windows headers), it's trivial to translate anyway, and it gives significant benefits to clarity. The really weird thing about the C syntax is that you can define a *function type* (not just function pointers). There's no D equivalent to that, although I'm not aware of any uses of the construct.

"There's no D equivalent to that", huh, how come not? D has an equivalent, in fact last time we ("we" meaning several people) talked about this we were discussing whether D should retain this C aspect or not: (http://www.digitalmars.com/d/archives/digitalmars/D/learn/4118.html) Or did I again miss some kind of difference?
 We're building up a list of features that should be deprecated:
 * 'length' inside slices.
 * C function syntax
 * C declaration syntax in general
 
 I'd also add:
 * some alternative to #line that doesn't waste the '#' symbol on such a 
 rarely-used feature.
 
 And there are probably a few more I've forgotten about.

-- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Dec 23 2006
prev sibling parent Ary Manzana <ary esperanto.org.ar> writes:
Chris Nicholson-Sauls escribió:
 Should we do this?  As in cause:
 
 # int foo[];
 # int bar*;
 
 And others to issue deprecation errors.  I think it would be a good 
 idea, and shouldn't break extern(C) declarations, so long as one doesn't 
 try to mix types.  (I don't think we can mix them in the C way at all, 
 anyhow.  Haven't tried, though.)  Or else change the rules such that 
 array/pointer decoration applies to the variable and not the type -- and 
 correct me if I'm wrong about this not being the current behavior.
 
 # int num   ,
 #     arr[] ,
 #     ptr*  ;
 
 vs
 
 # int   num ;
 # int[] arr ;
 # int*  ptr ;
 
 -- Chris Nicholson-Sauls

I want this too (to be deprecated)! I want it because of an UI problem. If you have: # int[] var; You can tell the type goes from position 0 and has length 5 and the name has position 6 and length 3. However, in # int var[]; the type and name are mixed. If you want to build an AST that fully represents a source code, including exact positions for each AST node, this is painful. You'd have an AST node for an ArrayType, and another for a Name, but... where does the ArrayType begin and end? Currently in the Descent plugin this information is not guaranteed to be correct in this kind of declarations, but yes in the former ones. I suggest this syntax to be deprecated. The plugin would allow you to convert a C-style declaration to a D-declaration automatically, it's very easy. I have the information of the AST nodes, and where the delcaration begins and end, so I can do it. In fact, if you write a C-style declaration, in the outline view you can see it in the D-style. :-)
Dec 21 2006