## digitalmars.D - Deprecate C style declerations?

• Chris Nicholson-Sauls (16/16) Dec 20 2006 Should we do this? As in cause:
• Jarrett Billingsley (11/28) Dec 20 2006 I agree, though
• Bill Baxter (11/24) Dec 20 2006 The syntax of static multidimensional arrays is better using C-style I
• Jarrett Billingsley (12/19) Dec 20 2006 That's true. In fact, I think there's a flag in the DMD frontend to mak...
• Bill Baxter (7/29) Dec 20 2006 Yeh, that's not a good enough reason to break the nice strict
• Gregor Richards (6/52) Dec 20 2006 Hear-hear! No need for C's crummy array syntax. Writing support for
• Hasan Aljudy (4/59) Dec 20 2006 Hear hear ..!
• Don Clugston (17/79) Dec 21 2006 I agree, too -- the main reason for retaining it was to simplify
• nazo (5/8) Dec 21 2006 I have a alternative suggestion which is syntax in comment for code like...
• Hasan Aljudy (8/93) Dec 21 2006 Let's hope Walter hears this before the dead line for v1.0
• Oskar Linde (12/23) Dec 21 2006 I kind of like Nazo's suggestion of putting it in a comment. Any
• Daniel Keep (16/32) Dec 23 2006 I use it!
• Don Clugston (13/49) Dec 23 2006 It's not about #line, just about the use of '#' for that single syntax
• Lars Ivar Igesund (9/26) Dec 29 2006 Yes, I believe this has been discussed before, although at greater lengt...
• Thomas Kuehne (11/18) Dec 21 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Jarrett Billingsley (11/12) Dec 21 2006 Much nicer looking, but unfortunately, there's a problem with it. Pragm...
• Bill Baxter (11/29) Dec 22 2006 It is a waste. So pragma's doen't work. I also hesitate to make some
• Thomas Kuehne (10/30) Dec 21 2006 -----BEGIN PGP SIGNED MESSAGE-----
• Kirk McDonald (7/8) Dec 21 2006 Oh, now I like that. Change it to this, and we can introduce # as a
• Bruno Medeiros (9/94) Dec 23 2006 "There's no D equivalent to that", huh, how come not? D has an
• Ary Manzana (18/41) Dec 21 2006 I want this too (to be deprecated)! I want it because of an UI problem.
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

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

vs

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

-- Chris Nicholson-Sauls

Dec 20 2006
"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
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

Dec 20 2006
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
"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
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
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
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

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

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

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

vs

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

I think that C "feature" was dropped in D because it makes multiple

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

* 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
nazo <lovesyao gmail.com> writes:
Don Clugston wrote:
* some alternative to #line that doesn't waste the '#' symbol on such a
rarely-used feature.

I have a alternative suggestion which is syntax in comment for code like:
//LINE: 12
//FIXME: this list is broken

Dec 21 2006
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

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

vs

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

I think that C "feature" was dropped in D because it makes multiple

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

* 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
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Hasan Aljudy wrote:

Don Clugston wrote:

* 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
Daniel Keep <daniel.keep+lists gmail.com> writes:
Hasan Aljudy wrote:

Don Clugston wrote:
* 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
Don Clugston <dac nospam.com.au> writes:
Daniel Keep wrote:
Hasan Aljudy wrote:
Don Clugston wrote:
* 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
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
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

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

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFFimaKLK5blCcjpWoRAkZCAJwNKgfp5xXjFLV/yZowJo2okfcqrgCdF6HE
EQsn2hTuI7xrgGapSL48Xsc=
=cOgp
-----END PGP SIGNATURE-----

Dec 21 2006
"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Thomas Kuehne" <thomas-dloop kuehne.cn> wrote in message
news:slrneokpko.mj5.thomas-dloop birke.kuehne.cn...

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

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

--bb

Dec 22 2006
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...

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

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

vs

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

I think that C "feature" was dropped in D because it makes multiple

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

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

# 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