www.digitalmars.com         C & C++   DMDScript  

D - More C/C++ Features to Drop

reply "Keith Nash" <k.j.nash usa.net> writes:
Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary legacy
features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses braces
"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.

These features are unhelpful, and lead to lots of bugs.  Why?  Because,
unlike compilers, programmers aren't good at keeping track of large numbers
of "{" and "}" in deeply nested structures.  So we indent our code with
whitespace, to make it more readable.  The problem is that bugs arise when
whitespace and braces disagree, e.g. in

if (blah) {
    if (blah)
    {
        blah;
        blah;
/* This comment is not in a good place */
}
else
{
    blah;
}
blah;
blah;
/* OK, this code does
 * blah blah
 */
}

This one's easy to spot, but you might be reading code that uses an
unfamiliar convention for positioning braces.
I agree that you can run the code through an indenter, or lint, but one
stated aim of D is to remove the features of C/C++ that make it necessary to
pre-check code in this way.  Indentation will always be the most convenient
way to make structured code readable to humans: the example D program itself
demonstrates this. So why not adopt indentation as a language feature?
Perhaps the syntax should be more like Python than like C/C++.

Freeform (";").  It's bad coding practice to put more than one statement on
a line; it makes code difficult to read.  Style guidelines tell us not to do
it.  Why not design D so that style guidelines are unnecessary (this too is
one of D's stated aims) - so that it is difficult, if not impossible, to
write bad code?  Use "newline", and only "newline", as a statement
terminator.

2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use something,
*anything*, in place of "==", even FORTRAN's ".EQ." would be better.



Whether or not you agree with these suggestions, I suggest that the language
syntax should not be exempt from examination and improvement; not least
because, after D has been released, we will no longer have the opportunity
to do this.

If you've read this far, thanks for reading.  I look forward to the day when
D replaces C/C++!

Best wishes,

Keith.
Jan 30 2002
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...

 Greetings,

 I'm interested in the D language - here's my 2c-worth.

 The website gives a list of features to drop, at
 http://www.digitalmars.com/d/overview.html
 and it is great that the D spec is so radical in dropping unnecessary


legacy

 features.  Here are my suggestions for a couple more.

 1. The C syntax.
 C syntax is freeform: it uses ";" to separate statements, and it uses


braces

 "{" and "}" to group statements together.  A good example of this is the
 example D program on the web page mentioned above.


There are a lot of Java, Perl, C, C++ programmers who are used to this.
I've not done any python, but I was under the impression it relied on the
indenting
a real pain if your editor changes tabs to spaces, and even if 1 tab == 4
spaces
not every one sets their tabstops the same.


 Freeform (";").  It's bad coding practice to put more than one statement


on

 a line; it makes code difficult to read.  Style guidelines tell us not to


do

 it.  Why not design D so that style guidelines are unnecessary (this too


is

 one of D's stated aims) - so that it is difficult, if not impossible, to
 write bad code?  Use "newline", and only "newline", as a statement
 terminator.


C programmers find ways round these problems, if you took away the ';' we'd
use the ',' more :)

consider:
   i = 9; a = buf[i]; b = a*i;
is the almost that same as
  i = 9, a = buf[i], b= a*i;

except that the latter will have a value of a*i.

or are you intending the all statements must fit onto oneline.

 2. Equality.
 Confusion of "=" and "==" is a common source of bugs.  Please use


something,

 *anything*, in place of "==", even FORTRAN's ".EQ." would be better.


personally I would prefer Pascal := as assign and == remains as equal to, if
you where to change anything.

Mike.
Jan 30 2002
parent reply Ruslanas Abdrachimovas <anubis 03bar.ktu.lt> writes:
Oooo, no. That's not very good. "==" and "=" bugs are very common in
C/C++ because int<->bool types are compatible in flow control 
statements, if they weren't there were only only one possibility:
if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
{                                         {
}                                         }

Sure, it could be nice that equal and assign operators were "strict" 
different (i.e. ":=" and "==", but of course not ":=" and "=", that 
would be the same problem for some people as "=" and "==").

Ruslanas

Mike Wynn wrote:


 "Keith Nash" <k.j.nash usa.net> wrote in message
 news:a39e2f$2gk9$1 digitaldaemon.com...
 

Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary


 legacy
 

features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses


 braces
 

"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.


 
 There are a lot of Java, Perl, C, C++ programmers who are used to this.
 I've not done any python, but I was under the impression it relied on the
 indenting
 a real pain if your editor changes tabs to spaces, and even if 1 tab == 4
 spaces
 not every one sets their tabstops the same.
 
 

Freeform (";").  It's bad coding practice to put more than one statement


 on
 

a line; it makes code difficult to read.  Style guidelines tell us not to


 do
 

it.  Why not design D so that style guidelines are unnecessary (this too


 is
 

one of D's stated aims) - so that it is difficult, if not impossible, to
write bad code?  Use "newline", and only "newline", as a statement
terminator.


 
 C programmers find ways round these problems, if you took away the ';' we'd
 use the ',' more :)
 
 consider:
    i = 9; a = buf[i]; b = a*i;
 is the almost that same as
   i = 9, a = buf[i], b= a*i;
 
 except that the latter will have a value of a*i.
 
 or are you intending the all statements must fit onto oneline.
 

2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use


 something,
 

*anything*, in place of "==", even FORTRAN's ".EQ." would be better.


 personally I would prefer Pascal := as assign and == remains as equal to, if
 you where to change anything.
 
 Mike.
Jan 31 2002
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
Actually I'm kinda partial to the way a very very old language did
assignment (the language that scripted the robots in Robot Wars on the
Apple ][, by Silas Warner if I remember correctly.  precursor to the CRobots
etc games).

It used

9 * x + 5 to a
a * speed * 3 to speed

that kind of thing.  Makes sense to read and also it's sorta easier to work
out what the machine will actually do because it reads left to right
consistently.  Parses easily for both machines and humans.  I also wouldn't
be opposed to using ->, now that that is removed from D.  Or --> or
whatever.

9 * x + 5 -> temp
temp * x - 3 -> speed

Either one definitely doesn't look like equality.  Then we could use regular
= for equality, which is also very intuitive for math folks.

Math doesn't use = as assignment, neither should programming languages.  I'm
not sure how *= , +=, etc would work in that case though...

One quirk with that language is that it didn't have unary minus (that's how
simple it was).  You had to use 0 - x.

I definitely don't like relying on indentation and newlines to delimit a
language...  but then again most of mine I just make the ; optional as most
of the time you can unambiguously tell when one expression or statement ends
and another begins (however not always, with C style grammars that allow
arbitrary expressions by themselves).

Maybe

put 9 * x + 5 in temp
put * x - 3 in speed

would clear that up cuz a statement could only be an assignment, function
call, loop, or logic, never any spurious crap like - x.  Nah, it'd never
work, I'm sure people would bitch about the extra typing.  <heh>

Sean


"Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
news:3C5907D3.3080507 03bar.ktu.lt...

 Oooo, no. That's not very good. "==" and "=" bugs are very common in
 C/C++ because int<->bool types are compatible in flow control
 statements, if they weren't there were only only one possibility:
 if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
 {                                         {
 }                                         }

 Sure, it could be nice that equal and assign operators were "strict"
 different (i.e. ":=" and "==", but of course not ":=" and "=", that
 would be the same problem for some people as "=" and "==").

 Ruslanas

 Mike Wynn wrote:


 "Keith Nash" <k.j.nash usa.net> wrote in message
 news:a39e2f$2gk9$1 digitaldaemon.com...


Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary


 legacy


features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses


 braces


"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.


 There are a lot of Java, Perl, C, C++ programmers who are used to this.
 I've not done any python, but I was under the impression it relied on




the

 indenting
 a real pain if your editor changes tabs to spaces, and even if 1 tab ==




4

 spaces
 not every one sets their tabstops the same.



Freeform (";").  It's bad coding practice to put more than one statement


 on


a line; it makes code difficult to read.  Style guidelines tell us not






to


 do


it.  Why not design D so that style guidelines are unnecessary (this too


 is


one of D's stated aims) - so that it is difficult, if not impossible, to
write bad code?  Use "newline", and only "newline", as a statement
terminator.


 C programmers find ways round these problems, if you took away the ';'




we'd

 use the ',' more :)

 consider:
    i = 9; a = buf[i]; b = a*i;
 is the almost that same as
   i = 9, a = buf[i], b= a*i;

 except that the latter will have a value of a*i.

 or are you intending the all statements must fit onto oneline.


2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use


 something,


*anything*, in place of "==", even FORTRAN's ".EQ." would be better.


 personally I would prefer Pascal := as assign and == remains as equal




to, if

 you where to change anything.

 Mike.







 Jan 31 2002



 next sibling parent reply Ruslanas Abdrachimovas <anubis 03bar.ktu.lt>  writes:


I don't like this. I think ":=" and "==" are good enough..., but 
something like this "+=" or "*=" we should leave as it is.

Ruslanas

Sean L. Palmer wrote:


 Actually I'm kinda partial to the way a very very old language did
 assignment (the language that scripted the robots in Robot Wars on the
 Apple ][, by Silas Warner if I remember correctly.  precursor to the CRobots
 etc games).
 
 It used
 
 9 * x + 5 to a
 a * speed * 3 to speed
 
 that kind of thing.  Makes sense to read and also it's sorta easier to work
 out what the machine will actually do because it reads left to right
 consistently.  Parses easily for both machines and humans.  I also wouldn't
 be opposed to using ->, now that that is removed from D.  Or --> or
 whatever.
 
 9 * x + 5 -> temp
 temp * x - 3 -> speed
 
 Either one definitely doesn't look like equality.  Then we could use regular
 = for equality, which is also very intuitive for math folks.
 
 Math doesn't use = as assignment, neither should programming languages.  I'm
 not sure how *= , +=, etc would work in that case though...
 
 One quirk with that language is that it didn't have unary minus (that's how
 simple it was).  You had to use 0 - x.
 
 I definitely don't like relying on indentation and newlines to delimit a
 language...  but then again most of mine I just make the ; optional as most
 of the time you can unambiguously tell when one expression or statement ends
 and another begins (however not always, with C style grammars that allow
 arbitrary expressions by themselves).
 
 Maybe
 
 put 9 * x + 5 in temp
 put * x - 3 in speed
 
 would clear that up cuz a statement could only be an assignment, function
 call, loop, or logic, never any spurious crap like - x.  Nah, it'd never
 work, I'm sure people would bitch about the extra typing.  <heh>
 
 Sean
 
 
 "Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
 news:3C5907D3.3080507 03bar.ktu.lt...
 

Oooo, no. That's not very good. "==" and "=" bugs are very common in
C/C++ because int<->bool types are compatible in flow control
statements, if they weren't there were only only one possibility:
if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
{                                         {
}                                         }

Sure, it could be nice that equal and assign operators were "strict"
different (i.e. ":=" and "==", but of course not ":=" and "=", that
would be the same problem for some people as "=" and "==").

Ruslanas

Mike Wynn wrote:



"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...



Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary


legacy



features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses


braces



"{" and "}" to group statements together.  A good example of this is the
example D program on the web page mentioned above.


There are a lot of Java, Perl, C, C++ programmers who are used to this.
I've not done any python, but I was under the impression it relied on




 the
 

indenting
a real pain if your editor changes tabs to spaces, and even if 1 tab ==




 4
 

spaces
not every one sets their tabstops the same.




Freeform (";").  It's bad coding practice to put more than one statement


on



a line; it makes code difficult to read.  Style guidelines tell us not






 to
 

do



it.  Why not design D so that style guidelines are unnecessary (this too


is



one of D's stated aims) - so that it is difficult, if not impossible, to
write bad code?  Use "newline", and only "newline", as a statement
terminator.


C programmers find ways round these problems, if you took away the ';'




 we'd
 

use the ',' more :)

consider:
   i = 9; a = buf[i]; b = a*i;
is the almost that same as
  i = 9, a = buf[i], b= a*i;

except that the latter will have a value of a*i.

or are you intending the all statements must fit onto oneline.



2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use


something,



*anything*, in place of "==", even FORTRAN's ".EQ." would be better.


personally I would prefer Pascal := as assign and == remains as equal




 to, if
 

you where to change anything.

Mike.




 
 





 Jan 31 2002



  parent  "Sean L. Palmer" <spalmer iname.com>  writes:


I'm not saying that D should use those syntax.  ;)  That's already pretty
much set in stone I think.

Sean


"Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
news:3C59367A.1070601 03bar.ktu.lt...

 I don't like this. I think ":=" and "==" are good enough..., but
 something like this "+=" or "*=" we should leave as it is.

 Ruslanas

 Sean L. Palmer wrote:


 Actually I'm kinda partial to the way a very very old language did
 assignment (the language that scripted the robots in Robot Wars on the
 Apple ][, by Silas Warner if I remember correctly.  precursor to the




CRobots

 etc games).

 It used

 9 * x + 5 to a
 a * speed * 3 to speed

 that kind of thing.  Makes sense to read and also it's sorta easier to




work

 out what the machine will actually do because it reads left to right
 consistently.  Parses easily for both machines and humans.  I also




wouldn't

 be opposed to using ->, now that that is removed from D.  Or --> or
 whatever.

 9 * x + 5 -> temp
 temp * x - 3 -> speed

 Either one definitely doesn't look like equality.  Then we could use




regular

 = for equality, which is also very intuitive for math folks.

 Math doesn't use = as assignment, neither should programming languages.




I'm

 not sure how *= , +=, etc would work in that case though...

 One quirk with that language is that it didn't have unary minus (that's




how

 simple it was).  You had to use 0 - x.

 I definitely don't like relying on indentation and newlines to delimit a
 language...  but then again most of mine I just make the ; optional as




most

 of the time you can unambiguously tell when one expression or statement




ends

 and another begins (however not always, with C style grammars that allow
 arbitrary expressions by themselves).

 Maybe

 put 9 * x + 5 in temp
 put * x - 3 in speed

 would clear that up cuz a statement could only be an assignment,




function

 call, loop, or logic, never any spurious crap like - x.  Nah, it'd never
 work, I'm sure people would bitch about the extra typing.  <heh>

 Sean


 "Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
 news:3C5907D3.3080507 03bar.ktu.lt...


Oooo, no. That's not very good. "==" and "=" bugs are very common in
C/C++ because int<->bool types are compatible in flow control
statements, if they weren't there were only only one possibility:
if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
{                                         {
}                                         }

Sure, it could be nice that equal and assign operators were "strict"
different (i.e. ":=" and "==", but of course not ":=" and "=", that
would be the same problem for some people as "=" and "==").

Ruslanas

Mike Wynn wrote:



"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...



Greetings,

I'm interested in the D language - here's my 2c-worth.

The website gives a list of features to drop, at
http://www.digitalmars.com/d/overview.html
and it is great that the D spec is so radical in dropping unnecessary


legacy



features.  Here are my suggestions for a couple more.

1. The C syntax.
C syntax is freeform: it uses ";" to separate statements, and it uses


braces



"{" and "}" to group statements together.  A good example of this is










the

example D program on the web page mentioned above.


There are a lot of Java, Perl, C, C++ programmers who are used to this.
I've not done any python, but I was under the impression it relied on




 the


indenting
a real pain if your editor changes tabs to spaces, and even if 1 tab ==




 4


spaces
not every one sets their tabstops the same.




Freeform (";").  It's bad coding practice to put more than one










statement


on



a line; it makes code difficult to read.  Style guidelines tell us not






 to


do



it.  Why not design D so that style guidelines are unnecessary (this










too


is



one of D's stated aims) - so that it is difficult, if not impossible,










to

write bad code?  Use "newline", and only "newline", as a statement
terminator.


C programmers find ways round these problems, if you took away the ';'




 we'd


use the ',' more :)

consider:
   i = 9; a = buf[i]; b = a*i;
is the almost that same as
  i = 9, a = buf[i], b= a*i;

except that the latter will have a value of a*i.

or are you intending the all statements must fit onto oneline.



2. Equality.
Confusion of "=" and "==" is a common source of bugs.  Please use


something,



*anything*, in place of "==", even FORTRAN's ".EQ." would be better.


personally I would prefer Pascal := as assign and == remains as equal




 to, if


you where to change anything.

Mike.











 Jan 31 2002



prev sibling next sibling parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3b30k$2npi$1 digitaldaemon.com...


 consistently.  Parses easily for both machines and humans.  I also


wouldn't

 be opposed to using ->, now that that is removed from D.  Or --> or
 whatever.

 9 * x + 5 -> temp
 temp * x - 3 -> speed


Knuth fan, eh? =)


 Math doesn't use = as assignment, neither should programming languages.


I'm

 not sure how *= , +=, etc would work in that case though...


Math uses :=



 Jan 31 2002



  parent reply "Sean L. Palmer" <spalmer iname.com>  writes:


 Math doesn't use = as assignment, neither should programming languages.


 I'm

 not sure how *= , +=, etc would work in that case though...


 Math uses :=


I thought Math used BASIC's "let"

let x = 5

which is kind of like "enforced" equality, which I guess works similarly to
assignment.

Sean



 Jan 31 2002



  parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3c4i8$dja$1 digitaldaemon.com...


 I thought Math used BASIC's "let"

 let x = 5

 which is kind of like "enforced" equality, which I guess works similarly


to

 assignment.


Mathematicians seem to dislike words, so they prefer symbols.
In the literature I've read, := was used for the assignment.
It's also so in MathCAD.

BTW BASIC's "LET" is abandoned for ages. Not even all
compilers support it - my does tho =)



 Jan 31 2002



  parent  "Juan Carlos Arevalo Baeza" <jcab roningames.com>  writes:


"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3c5vu$m9h$1 digitaldaemon.com...

 "Sean L. Palmer" <spalmer iname.com> wrote in message
 news:a3c4i8$dja$1 digitaldaemon.com...


 I thought Math used BASIC's "let"

 let x = 5

 which is kind of like "enforced" equality, which I guess works similarly


 to

 assignment.


 Mathematicians seem to dislike words, so they prefer symbols.
 In the literature I've read, := was used for the assignment.
 It's also so in MathCAD.

 BTW BASIC's "LET" is abandoned for ages. Not even all
 compilers support it - my does tho =)


   "let" is still widely used in functional languages (Haskell, ML et al).
Its meaning is NOT assignment. It is a definition of a constant value, used
for convenience and to improve performance. So:

let x = y+1

   is equivalent to the C++:

const <put type here> x = y + 1;

   Note that:

let x = x + 1

   is a bottomless recursive computation (effectively an infinite loop that
eventually runs out of stack).

Salutaciones,
                         JCAB



 Jan 31 2002



prev sibling  parent reply "Walter" <walter digitalmars.com>  writes:


"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3b30k$2npi$1 digitaldaemon.com...

 It used

 9 * x + 5 to a
 a * speed * 3 to speed

 that kind of thing.  Makes sense to read and also it's sorta easier to


work

 out what the machine will actually do because it reads left to right
 consistently.  Parses easily for both machines and humans.  I also


wouldn't

 be opposed to using ->, now that that is removed from D.  Or --> or
 whatever.


That will work, but it's too different from the look and feel of C.


 I definitely don't like relying on indentation and newlines to delimit a
 language...  but then again most of mine I just make the ; optional as


most

 of the time you can unambiguously tell when one expression or statement


ends

 and another begins (however not always, with C style grammars that allow
 arbitrary expressions by themselves).


Javascript has optional semicolons. It sounds like a good idea, but in
practice it causes a lot of subtle problems with the parser. Some level of
redundancy is necessary in a useful language, because it enables the
compilers to detect errors. No redundancy means that any stream of random
tty noise is a valid program. Requiring semicolons in C enables more typo
errors to be diagnosed at compile time rather than at debug time. Too much
redundancy, however, makes a language just annoying to program in <g>.



 Feb 01 2002



  parent reply "D" <s_nudds hotmail.com>  writes:


Semicolons aren't redundant in C/C++ whitespace and <EOL> are ignored.  As a
result semicolons are considered <EOL>.  There is no significant problems
caused by considering the real <EOL> to be equivalent to a semicolon with
the exception that you lose the ability to spread single statments over
multiple lines.  To that end, you have to define another symbol as a line
continuation symbol.  When this symbol is encountered, the next true <EOL>
is ignored.

It's as simple as that.



 Javascript has optional semicolons. It sounds like a good idea, but in
 practice it causes a lot of subtle problems with the parser. Some level of
 redundancy is necessary in a useful language, because it enables the
 compilers to detect errors. No redundancy means that any stream of random
 tty noise is a valid program. Requiring semicolons in C enables more typo
 errors to be diagnosed at compile time rather than at debug time. Too much
 redundancy, however, makes a language just annoying to program in <g>.





 Feb 03 2002



 next sibling parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"D" <s_nudds hotmail.com> wrote in message
news:a3lf84$pao$1 digitaldaemon.com...


 Semicolons aren't redundant in C/C++ whitespace and <EOL> are ignored.  As


a

 result semicolons are considered <EOL>.  There is no significant problems
 caused by considering the real <EOL> to be equivalent to a semicolon with
 the exception that you lose the ability to spread single statments over
 multiple lines.  To that end, you have to define another symbol as a line
 continuation symbol.  When this symbol is encountered, the next true <EOL>
 is ignored.

 It's as simple as that.


Not really. Some languages (Euphoria, Lua - those I know well) don't use
statement delimiters at all. You can write:

    if a = 1 then a += 1 end

    -- or --

    if a = 1 then
        a += 1
    end

    -- or even --

    if a
    = 1 then a
    += 1 end

Still, I prefer to have semicolons. They make life easier when reading
code, and help compiler to parse some complicated cases.



 Feb 04 2002



  parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org>  writes:


Isn't 'end' the statement delimiter in the examples below?

Pavel Minayev wrote:


     if a = 1 then a += 1 end

     -- or --

     if a = 1 then
         a += 1
     end

     -- or even --

     if a
     = 1 then a
     += 1 end

 Still, I prefer to have semicolons. They make life easier when reading
 code, and help compiler to parse some complicated cases.


--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]



 Feb 04 2002



  parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C5ECA86.97EDD361 deming-os.org...


 Isn't 'end' the statement delimiter in the examples below?


No, it's end of block, not end of statement. You
could see something like this in Lua:

    function foo(a, b) a += 1
    bar() if a > 10 then a = 0
    end baz(a) end

Just a legal piece of code =)



 Feb 04 2002



  parent  Russ Lewis <spamhole-2001-07-16 deming-os.org>  writes:


k, I see now :)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]



 Feb 04 2002



prev sibling  parent  "Sean L. Palmer" <spalmer iname.com>  writes:


Sounds like a PITA... not a good tradeoff.

Sean

"D" <s_nudds hotmail.com> wrote in message
news:a3lf84$pao$1 digitaldaemon.com...

 Semicolons aren't redundant in C/C++ whitespace and <EOL> are ignored.  As


a

 result semicolons are considered <EOL>.  There is no significant problems
 caused by considering the real <EOL> to be equivalent to a semicolon with
 the exception that you lose the ability to spread single statments over
 multiple lines.  To that end, you have to define another symbol as a line
 continuation symbol.  When this symbol is encountered, the next true <EOL>
 is ignored.

 It's as simple as that.



 Javascript has optional semicolons. It sounds like a good idea, but in
 practice it causes a lot of subtle problems with the parser. Some level




of

 redundancy is necessary in a useful language, because it enables the
 compilers to detect errors. No redundancy means that any stream of




random

 tty noise is a valid program. Requiring semicolons in C enables more




typo

 errors to be diagnosed at compile time rather than at debug time. Too




much

 redundancy, however, makes a language just annoying to program in <g>.







 Feb 04 2002



prev sibling next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk>  writes:


I never sugested '=' (single equals as equality)

I guess I should have said ;
have a real boolean like Java so none of the
int a ; if ( a ) {...} and more of : int a; if ( a == 0 ) { ... }
that's equal equal like C/D/Java/etc etc
that's about 80% of the '=' "==" bugs
them replace assign ('=') with ":=" Like Pascal etc
this is inline with all the += <<= -= operators;
straight assign not operator assign
and '=' is never to be seen.
 you can't have
int a; if ( a := b ) {.. }
instead
int a; if ( (a := b) == 0 ) {.. }
I've not heard a java programmer complain about having to add 3/4 extra
symbols
as the time spent is well worth it.
and the compiled code is the same (try it with your C compiler)

Mike.

"Ruslanas Abdrachimovas" <anubis 03bar.ktu.lt> wrote in message
news:3C5907D3.3080507 03bar.ktu.lt...

 Oooo, no. That's not very good. "==" and "=" bugs are very common in
 C/C++ because int<->bool types are compatible in flow control
 statements, if they weren't there were only only one possibility:
 if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)
 {                                         {
 }                                         }

 Sure, it could be nice that equal and assign operators were "strict"
 different (i.e. ":=" and "==", but of course not ":=" and "=", that
 would be the same problem for some people as "=" and "==").

 Ruslanas

 Mike Wynn wrote:




 personally I would prefer Pascal := as assign and == remains as equal




to, if

 you where to change anything.

 Mike.







 Jan 31 2002



  parent reply "Pavel Minayev" <evilone omen.ru>  writes:


D has "real" bools (bits are), it's just syntax-relaxed.



 Jan 31 2002



 next sibling parent  "Pavel Minayev" <evilone omen.ru>  writes:


 D has "real" bools (bits are), it's just syntax-relaxed.


BTW, Walter, could you please define binary operators on
bit so it doesn't get converted to byte - so that ~true
is false, not 0xfe =)



 Jan 31 2002



prev sibling  parent reply "Mike Wynn" <mike.wynn l8night.co.uk>  writes:


A bit is a bit, a boolean is not (it can be reprosented as one)
but (a < 8) does not eval to a bit, it should eval to a boolean
which could be a bit or an int.

real booleans is a concept, not a physical storage, how the compiler
internally represents then is up to it, to use a bit to make a boolean a bit
would allow
bit a;
if ( a = 1 ) { ... } to pass without warning, which is not wanted
booleans have the value true or false (keywords) not numeric values
there is not conversion from int to bool but bool to int is 0 false, true 1
so the C habit of doing a =!!a;
becomes a = (a!=0);
or a= !(a==0);
that's my 10c

Mike.
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3c21m$2hmd$1 digitaldaemon.com...

 D has "real" bools (bits are), it's just syntax-relaxed.





 Jan 31 2002



  parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:a3c6b9$n9e$1 digitaldaemon.com...


 A bit is a bit, a boolean is not (it can be reprosented as one)
 but (a < 8) does not eval to a bit, it should eval to a boolean
 which could be a bit or an int.

 real booleans is a concept, not a physical storage, how the compiler
 internally represents then is up to it, to use a bit to make a boolean a


bit

 would allow
 bit a;
 if ( a = 1 ) { ... } to pass without warning, which is not wanted
 booleans have the value true or false (keywords) not numeric values
 there is not conversion from int to bool but bool to int is 0 false, true


1

 so the C habit of doing a =!!a;
 becomes a = (a!=0);
 or a= !(a==0);
 that's my 10c


I've got used to C's relaxed type-checking... but I understand
the benefits of having a separate bool type. Actually, I don't
mind if there is one or not.



 Jan 31 2002



  parent reply "D" <s_nudds hotmail.com>  writes:


With respect to boolean types, it is essential that the language have
predefined constants for true and false.


 I've got used to C's relaxed type-checking... but I understand
 the benefits of having a separate bool type. Actually, I don't
 mind if there is one or not.





 Feb 03 2002



  parent  "Pavel Minayev" <evilone omen.ru>  writes:


"D" <s_nudds hotmail.com> wrote in message
news:a3lfdg$php$1 digitaldaemon.com...


 With respect to boolean types, it is essential that the language have
 predefined constants for true and false.


D has both. true is 0, false is 1. Both are of type bit.



 Feb 04 2002



prev sibling  parent reply Karl Bochert <kbochert ix.netcom.com>  writes:


On Thu, 31 Jan 2002 11:01:07 +0200, Ruslanas Abdrachimovas
<anubis 03bar.ktu.lt> wrote:

 Oooo, no. That's not very good. "==" and "=" bugs are very common in
 C/C++ because int<->bool types are compatible in flow control 
 statements, if they weren't there were only only one possibility:
 if (bool_expr1 == bool_expr2)     OR      if (bool_expr1 = bool_expr2)


Disallow  assignments in all conditionals. They are  unnecessary,  confusing
and prone to error with any syntax.



 Jan 31 2002



  parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk>  writes:


Hi,

I'm new here, but have read the specs and followed this group with great
interrest for a few days.

"Karl Bochert" <kbochert ix.netcom.com> wrote in message
news:1103_1012528774 bose...

 Disallow  assignments in all conditionals. They are  unnecessary,


confusing

 and prone to error with any syntax.


I don't agree with you one this. Consider this C/C++ example:

    while ( ch=fgetc(fp), ch!=EOF && ch!='\n' ) {
        ...
    }

without the assignment it might become:

    for (;;) {
        ch = fgetc(fp);
        if (ch==EOF || ch=='\n') {
            break;
        }
        ...
    }

and the condition is moved into the loop, which I prefer to avoid if there
is a simple solution to it.

The for-construction above isn't valid D code according to the specs,
because the increment cannot be omitted in D. Anyway, I prefer for(;;) over
while(true) as the latter might lead to warnings about constant conditionals
(such warnings are often very useful). For this reason I would like to see
some construction that allows an "indefinite" loop without constant
expressions. It might be for(;;), but a "forever" loop construction would
please me just as much.

Regards,
Martin



 Feb 01 2002



 next sibling parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:a3edhg$uuk$1 digitaldaemon.com...


 The for-construction above isn't valid D code according to the specs,
 because the increment cannot be omitted in D. Anyway, I prefer for(;;)


over

for(;;) compiles fine.


 while(true) as the latter might lead to warnings about constant


conditionals

 (such warnings are often very useful). For this reason I would like to see
 some construction that allows an "indefinite" loop without constant
 expressions. It might be for(;;), but a "forever" loop construction would
 please me just as much.


I've asked this before... but it seems that most people here don't
really need it. Still it'd be pretty fine to have. I suggest while() -
with no expession inside the braces - for this purpose, to avoid
new keywords.



 Feb 01 2002



  parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org>  writes:


Pavel Minayev wrote:


 I've asked this before... but it seems that most people here don't
 really need it. Still it'd be pretty fine to have. I suggest while() -
 with no expession inside the braces - for this purpose, to avoid
 new keywords.


I don't have the exact quote, but Walter's quote was something like:

"I've been programming C so long that    for(i=0; i<10; i++)    looks pretty
much like a keyword to me."

It is cool that some things are so well known that they function like keywords
even though they aren't.  IMHO, that's almost better than keywords...it requires
less forking of the "familiarity base"

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]



 Feb 01 2002



  parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C5AD3A2.5C83B700 deming-os.org...


 I don't have the exact quote, but Walter's quote was something like:

 "I've been programming C so long that    for(i=0; i<10; i++)    looks


pretty

 much like a keyword to me."


It was related to my topic about for-each. I still think that some
form of for-each would be a great advantage for the language, BTW.



 Feb 01 2002



  parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org>  writes:


Although I hated it at first, I have grown to (kind of) like shell
scripting's for construct:

    for <varname> in <list of items>
    do
       <run once for each item, with <varname>=<item>>
    done

I'm not sure of the right C-style syntax for this, but it would be cool to
have.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]



 Feb 01 2002



  parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C5AE2AE.C870DB58 deming-os.org...


 Although I hated it at first, I have grown to (kind of) like shell
 scripting's for construct:

     for <varname> in <list of items>
     do
        <run once for each item, with <varname>=<item>>
     done

 I'm not sure of the right C-style syntax for this, but it would be cool to
 have.


Yeah, exactly. I suggest either:

    foreach (var in array) ...    // was it in JavaScript? I don't
remember...
                                  // problem is "in" has other meaning
already

    -- or --

    foreach (array as var) ...    // PHP-like



 Feb 01 2002



  parent  Alex Vincent <jscript pacbell.net>  writes:


     foreach (var in array) ...    // was it in JavaScript? I don't
 remember...


Actually, it's:

for (property in object) {
/* actions.  property is a string, object[property] is the actual 
property */



 Feb 01 2002



prev sibling next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org>  writes:


"Martin M. Pedersen" wrote:


 I don't agree with you one this. Consider this C/C++ example:

     while ( ch=fgetc(fp), ch!=EOF && ch!='\n' ) {
         ...
     }

 without the assignment it might become:

     for (;;) {
         ch = fgetc(fp);
         if (ch==EOF || ch=='\n') {
             break;
         }
         ...
     }

 and the condition is moved into the loop, which I prefer to avoid if there
 is a simple solution to it.


Try this.  It's still not perfect, but it's a little better:

    ch = fgetc(fp);
    while(ch!=EOF && ch!='\n') {
        ...
    }

I don't like the duplicated line, but it works for lack of something better.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]



 Feb 01 2002



  parent  "Martin M. Pedersen" <mmp www.moeller-pedersen.dk>  writes:


Hi,

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3C5AD45E.969DDE7D deming-os.org...


 Try this.  It's still not perfect, but it's a little better:

     ch = fgetc(fp);
     while(ch!=EOF && ch!='\n') {
         ...
     }

 I don't like the duplicated line,


You obviously does not :-) I know what you intended to write, and I don't
either.


 but it works for lack of something better.


It is really a matter of taste, and personal experiences on how errors are
introduced. I find the version without redundant calls to fgetc() less error
prone because you only have to replace fgetc() once in case you need to do
so. So, I'm sure the version I wrote first is something better for me.

Regards,
Martin M. Pedersen



 Feb 01 2002



prev sibling  parent reply "D" <s_nudds hotmail.com>  writes:


land = logical and
lor = logical or
leq = logical equal

& = binary and
|  = binary or
= = binary equal


  = logical shift right




<< = logical shift left
o> = Roll Right
o< = Roll Left

do
   ch = fgetc(fp)
   if (ch != EOF land ch !=  EOL) then exit
  ...
loop


 I don't agree with you one this. Consider this C/C++ example:

     while ( ch=fgetc(fp), ch!=EOF && ch!='\n' ) {
         ...
     }

 without the assignment it might become:

     for (;;) {
         ch = fgetc(fp);
         if (ch==EOF || ch=='\n') {
             break;
         }
         ...
     }

 and the condition is moved into the loop, which I prefer to avoid if there
 is a simple solution to it.

 The for-construction above isn't valid D code according to the specs,
 because the increment cannot be omitted in D. Anyway, I prefer for(;;)


over

 while(true) as the latter might lead to warnings about constant


conditionals

 (such warnings are often very useful). For this reason I would like to see
 some construction that allows an "indefinite" loop without constant
 expressions. It might be for(;;), but a "forever" loop construction would
 please me just as much.

 Regards,
 Martin





 Feb 04 2002



  parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"D" <s_nudds hotmail.com> wrote in message
news:a3lgkl$qpp$1 digitaldaemon.com...


 land = logical and
 lor = logical or
 leq = logical equal


Why not then simply "and" & "or" & "eq", and where is "not"?.
And why don't you like && || ?


  = logical shift right




 << = logical shift left


LOGICAL SHIFT???


 do
    ch = fgetc(fp)
    if (ch != EOF land ch !=  EOL) then exit
   ...
 loop


No Pascal, please =)

    while (true)
    {
        ...
    }



 Feb 04 2002



 next sibling parent reply Russell Borogove <kaleja estarcion.com>  writes:


Pavel Minayev wrote:


 "D" <s_nudds hotmail.com> wrote in message
 news:a3lgkl$qpp$1 digitaldaemon.com...




  >> = logical shift right

  << = logical shift left


 
 LOGICAL SHIFT???



Logical shift = unsigned shift = not arithmetic shift = don't
shift in sign bits. Doesn't make a difference to the left
shift, obviously.



 Feb 04 2002



  parent  "Pavel Minayev" <evilone omen.ru>  writes:


"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C5EBDCD.5040504 estarcion.com...


 Logical shift = unsigned shift = not arithmetic shift = don't
 shift in sign bits. Doesn't make a difference to the left
 shift, obviously.


Ahh... sorry, didn't know how it's called "logical".



 Feb 04 2002



prev sibling  parent  "D" <s_nudds hotmail.com>  writes:


Pavel Minayev <evilone omen.ru> wrote in message
news:a3ll7u$svm$1 digitaldaemon.com...


 Why not then simply "and" & "or" & "eq", and where is "not"?.
 And why don't you like && || ?


&& does not in itself imply a "logical" operation rather than a numerical
one.  l& has an advantage over && in the regard.  Having said that, "land"
has both benefits and problems.  As long as there is a consistant
distinction made for logial vs numerical operations.

In C, we have = numeric == logical
                     & numeric && logical
                     | numeric || logical

and now the inconsistancy

                    < logical  << numeric
                    > logical  >> numeric

Very unfortunate.



  = logical shift right




 << = logical shift left


 LOGICAL SHIFT???


Sorry Assembler vocab.




 do
    ch = fgetc(fp)
    if (ch != EOF land ch !=  EOL) then exit
   ...
 loop


 No Pascal, please =)

     while (true)
     {
         ...
     }


Inferior.

Simple brackets are inferior for a variety of reasons.
In the above instance the opening brace is redundant and wastes a line of
space.  The block can start at the end of the conditional with no loss of
clarity.

Second, there is no type to the closing brace.  Lack of block typing makes a
language prone to block grouping errors.  Indention is a poor replacement
for proper language typing.  Youi might as well omit variable typing and
stipulate that variables the end with one brace are integers, two braces are
floats, etc.

Block typing is good.  Use it.



 Feb 04 2002



prev sibling next sibling parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...


 1. The C syntax.
 C syntax is freeform: it uses ";" to separate statements, and it uses


braces

 "{" and "}" to group statements together.  A good example of this is the
 example D program on the web page mentioned above.

 These features are unhelpful, and lead to lots of bugs.  Why?  Because,
 unlike compilers, programmers aren't good at keeping track of large


numbers

 of "{" and "}" in deeply nested structures.  So we indent our code with
 whitespace, to make it more readable.  The problem is that bugs arise when
 whitespace and braces disagree, e.g. in


...

 Perhaps the syntax should be more like Python than like C/C++.


We C guys have all got so used to it, I don't think it's a good
idea to drop this syntax...


 Freeform (";").  It's bad coding practice to put more than one statement


on

 a line; it makes code difficult to read.  Style guidelines tell us not to


do

 it.  Why not design D so that style guidelines are unnecessary (this too


is

 one of D's stated aims) - so that it is difficult, if not impossible, to
 write bad code?  Use "newline", and only "newline", as a statement
 terminator.


BASIC once was like that. Now we can use colon to put several
statements on one line. Sometimes, it just looks better - and
clearer.


 2. Equality.
 Confusion of "=" and "==" is a common source of bugs.  Please use


something,

 *anything*, in place of "==", even FORTRAN's ".EQ." would be better.


Then better use Pascal syntax, := for assigning and == for comparison.
Or even better, leave it as is =) I like it this way



 Jan 31 2002



  parent reply "D" <s_nudds hotmail.com>  writes:


C syntax is a fine model to follow if you wish to continually repeat the
same perpetually exposed errors.

I recommend avoiding errors.

Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
token.

Pavel Minayev <evilone omen.ru> wrote in message
news:a3c1ts$2hln$1 digitaldaemon.com...

 "Keith Nash" <k.j.nash usa.net> wrote in message
 news:a39e2f$2gk9$1 digitaldaemon.com...



 We C guys have all got so used to it, I don't think it's a good
 idea to drop this syntax...





 Feb 04 2002



 next sibling parent reply "Pavel Minayev" <evilone omen.ru>  writes:


"D" <s_nudds hotmail.com> wrote in message
news:a3lh1c$qtg$1 digitaldaemon.com...


 C syntax is a fine model to follow if you wish to continually repeat the
 same perpetually exposed errors.

 I recommend avoiding errors.

 Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
 token.


BASIC fan, eh? =)
Just indent code properly, and everything is very readable. In
fact, C/C++/D code is sometimes more readable than BASIC or
Pascal one, because you read much less junk.



 Feb 04 2002



  parent  "D" <s_nudds hotmail.com>  writes:


 "D" <s_nudds hotmail.com> wrote in message

 C syntax is a fine model to follow if you wish to continually repeat the
 same perpetually exposed errors.
 Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
 token.




Pavel Minayev <evilone omen.ru> wrote in message
news:a3lla6$svt$1 digitaldaemon.com...

 BASIC fan, eh? =)


I am, but I don't propose the method because it's the one chosen by
MSBasics.  It is simply a fact that
line continuation is less common that <EOL>.  It is also a fact that
semicolons are commonly omited and their omission causes trouble. Not
requiring them is therefore superior.


Pavel Minayev <evilone omen.ru> wrote in message
news:a3lla6$svt$1 digitaldaemon.com...

 Just indent code properly, and everything is very readable. In
 fact, C/C++/D code is sometimes more readable than BASIC or
 Pascal one, because you read much less junk.


The fact that C/C++ does not have block typing means that it is error prone
and less readable than those langauges that have it.

I don't recommend perpetually repeating the foolish mistakes of the past.



 Feb 04 2002



prev sibling  parent  "Sean L. Palmer" <spalmer iname.com>  writes:


Yeah, we've heard you already.

Sean

"D" <s_nudds hotmail.com> wrote in message
news:a3lh1c$qtg$1 digitaldaemon.com...

 C syntax is a fine model to follow if you wish to continually repeat the
 same perpetually exposed errors.

 I recommend avoiding errors.

 Use ";" optionally.  EOL = ";" unless prefixed with a line continuation
 token.

 Pavel Minayev <evilone omen.ru> wrote in message
 news:a3c1ts$2hln$1 digitaldaemon.com...

 "Keith Nash" <k.j.nash usa.net> wrote in message
 news:a39e2f$2gk9$1 digitaldaemon.com...



 We C guys have all got so used to it, I don't think it's a good
 idea to drop this syntax...







 Feb 04 2002



prev sibling  parent reply "Brian Bober" <netdemonz yahoo.com>  writes:


"Keith Nash" <k.j.nash usa.net> wrote in message
news:a39e2f$2gk9$1 digitaldaemon.com...

 Greetings,

 I'm interested in the D language - here's my 2c-worth.

 The website gives a list of features to drop, at
 http://www.digitalmars.com/d/overview.html
 and it is great that the D spec is so radical in dropping unnecessary


legacy

 features.  Here are my suggestions for a couple more.

 1. The C syntax.
 C syntax is freeform: it uses ";" to separate statements, and it uses


braces

 "{" and "}" to group statements together.  A good example of this is the
 example D program on the web page mentioned above.


This would be a problem for cross-platform code. I'm happy with the syntax.
What I would like to see is an
ability to do multi-line strings.


 These features are unhelpful, and lead to lots of bugs.  Why?  Because,
 unlike compilers, programmers aren't good at keeping track of large


numbers

 of "{" and "}" in deeply nested structures.  So we indent our code with
 whitespace, to make it more readable.  The problem is that bugs arise when
 whitespace and braces disagree, e.g. in

 if (blah) {
     if (blah)
     {
         blah;
         blah;
 /* This comment is not in a good place */
 }
 else
 {
     blah;
 }
 blah;
 blah;
 /* OK, this code does
  * blah blah
  */
 }

 This one's easy to spot, but you might be reading code that uses an
 unfamiliar convention for positioning braces.
 I agree that you can run the code through an indenter, or lint, but one
 stated aim of D is to remove the features of C/C++ that make it necessary


to

 pre-check code in this way.  Indentation will always be the most


convenient

 way to make structured code readable to humans: the example D program


itself

 demonstrates this. So why not adopt indentation as a language feature?
 Perhaps the syntax should be more like Python than like C/C++.

 Freeform (";").  It's bad coding practice to put more than one statement


on

 a line; it makes code difficult to read.  Style guidelines tell us not to


do

 it.  Why not design D so that style guidelines are unnecessary (this too


is

 one of D's stated aims) - so that it is difficult, if not impossible, to
 write bad code?  Use "newline", and only "newline", as a statement
 terminator.


How about a warning or error if two statements are on the same line?


 2. Equality.
 Confusion of "=" and "==" is a common source of bugs.  Please use


something,

 *anything*, in place of "==", even FORTRAN's ".EQ." would be better.



 Whether or not you agree with these suggestions, I suggest that the


language

 syntax should not be exempt from examination and improvement; not least
 because, after D has been released, we will no longer have the opportunity
 to do this.

 If you've read this far, thanks for reading.  I look forward to the day


when

 D replaces C/C++!

 Best wishes,

 Keith.





 Feb 03 2002



  parent  "Pavel Minayev" <evilone omen.ru>  writes:


"Brian Bober" <netdemonz yahoo.com> wrote in message
news:a3lcbu$mp5$1 digitaldaemon.com...


 What I would like to see is an
 ability to do multi-line strings.


char[] s =
    "first line\n"
    "second line\n"
    "third line\n"
    ... ;


 How about a warning or error if two statements are on the same line?


This is the same as defining EOL as end-of-statement. And I won't
be able to write something like this?

    a++; b++;
    c = a + b;

Never ever! =)



 Feb 04 2002