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:




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.





vs





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




 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.





 vs






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:




 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:




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.





vs






 
 
 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:




 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.





 vs







 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:




 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.





 vs







 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
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
 rarely-used feature.


I have a alternative suggestion which is syntax in comment for code like:
//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:




 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.





 vs







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



 (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
 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.
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.
 

 
 


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"




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.
 






 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:





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:




 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.





 vs







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


 
 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.
 



 
 vs
 



 
 -- Chris Nicholson-Sauls


I want this too (to be deprecated)! I want it because of an UI problem. 
If you have:



You can tell the type goes from position 0 and has length 5 and the name 
has position 6 and length 3. However, in



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