www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Restricting ++ and --

reply bearophile <bearophileHUGS lycos.com> writes:
This post is born from a bug I've just removed.
In the past I have read more than one C coding standard (or better, lists of
coding tips) that warn against bugs caused by ++ and --. They suggest to not
use them compound in expressions. They allow to use them when alone on an
instruction.

Python designers have totally avoided to put those operators in the language,
with the rationale they are bug-prone while saving just a little of typing.

Removing those operators from D, as Python, may look excessive. So a possible
compromise can be:
- Deprecate the pre versions:  --x  and ++x
- Make them return void, so they can't be used as expressions like this:
y = x++;
foo(x--);
You have to use them as:
x++; y = x;
x--; foo(x);
(So ++ and -- become similar to the Inc() and Dec() functions of Pascal).

What problems such changes may cause?

Bye,
bearophile
Oct 25 2009
next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Sun, 25 Oct 2009 12:33:13 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:


 - Make them return void, so they can't be used as expressions like this:
 y = x++;
 foo(x--);
 You have to use them as:
 x++; y = x;
 x--; foo(x);
 (So ++ and -- become similar to the Inc() and Dec() functions of Pascal).


No way. I've written items[itemCount++] way too often to give that up.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com
Oct 25 2009
prev sibling next sibling parent reply d-noob <doesnt exist.com> writes:
bearophile Wrote:


 This post is born from a bug I've just removed.
 In the past I have read more than one C coding standard (or better, lists of
coding tips) that warn against bugs caused by ++ and --. They suggest to not
use them compound in expressions. They allow to use them when alone on an
instruction.
 
 Python designers have totally avoided to put those operators in the language,
with the rationale they are bug-prone while saving just a little of typing.
 
 Removing those operators from D, as Python, may look excessive. So a possible
compromise can be:
 - Deprecate the pre versions:  --x  and ++x
 - Make them return void, so they can't be used as expressions like this:
 y = x++;
 foo(x--);
 You have to use them as:
 x++; y = x;
 x--; foo(x);
 (So ++ and -- become similar to the Inc() and Dec() functions of Pascal).
 
 What problems such changes may cause?


Apparently you want to change postInc/Dec to be statements to prevent them from
returning values (otherwise the expr semantics would need a special case). That
would break C compatibility and sounds ridiculous.
Oct 25 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
d-noob:


That would break C compatibility and sounds ridiculous.<


It breaks C compatibility, but it doesn't assign a new meaning to a C syntax,
it just disallows a syntax used in C, and this is allowed by D philosophy.

Many of the things I say sound ridiculous :-)
You may say it's not a handy change and you may refuse it, but I think it's not
a ridiculous idea because those changes lead to code that's equal to how some
expert coders suggest to program to avoid bugs, this is one of them, but I have
seen two more:
http://users.bestweb.net/~ctips/tip037.html
So it's a language enforcement of a coding tip/standard.

Bye,
bearophile
Oct 25 2009
next sibling parent d-noob <doesnt exist.com> writes:
bearophile Wrote:


 d-noob:
 

That would break C compatibility and sounds ridiculous.<


 
 It breaks C compatibility, but it doesn't assign a new meaning to a C syntax,
it just disallows a syntax used in C, and this is allowed by D philosophy.
 
 Many of the things I say sound ridiculous :-)
 You may say it's not a handy change and you may refuse it, but I think it's
not a ridiculous idea because those changes lead to code that's equal to how
some expert coders suggest to program to avoid bugs, this is one of them, but I
have seen two more:
 http://users.bestweb.net/~ctips/tip037.html
 So it's a language enforcement of a coding tip/standard.


Might be so. I don't personally like C code like
  int c;
  c = (c++), (--c), (++c);

But there has to be a middle ground. Lately there has been many attempts at
removing C like parts of the grammar, but that will harm D in the long run.
Once the C/C++ crowd realizes how good D is, they will only convert if there is
a safe syntactical path.
Oct 25 2009
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 d-noob:

That would break C compatibility and sounds ridiculous.<


 It breaks C compatibility, but it doesn't assign a new meaning to a C syntax,
it


just disallows a syntax used in C, and this is allowed by D philosophy.

 Many of the things I say sound ridiculous :-)
 You may say it's not a handy change and you may refuse it, but I think it's not


a ridiculous idea because those changes lead to code that's equal to how some
expert coders suggest to program to avoid bugs, this is one of them, but I have
seen two more:

 http://users.bestweb.net/~ctips/tip037.html
 So it's a language enforcement of a coding tip/standard.


In other words, bondage and discipline.  The legitimate role of a language
designer for a systems language is to make it hard to shoot yourself in the foot
*by accident* and to provide sane *defaults*.  IMHO no language designer, not
even
Walter, should take it upon himself/herself enforce his/her view of "correct" or
"safe" programming style on me through arbitrary restrictions on what the
language
can do.


 Bye,
 bearophile
Oct 25 2009
prev sibling parent grauzone <none example.net> writes:
d-noob wrote:

 bearophile Wrote:
 

 This post is born from a bug I've just removed.
 In the past I have read more than one C coding standard (or better, lists of
coding tips) that warn against bugs caused by ++ and --. They suggest to not
use them compound in expressions. They allow to use them when alone on an
instruction.

 Python designers have totally avoided to put those operators in the language,
with the rationale they are bug-prone while saving just a little of typing.

 Removing those operators from D, as Python, may look excessive. So a possible
compromise can be:
 - Deprecate the pre versions:  --x  and ++x
 - Make them return void, so they can't be used as expressions like this:
 y = x++;
 foo(x--);
 You have to use them as:
 x++; y = x;
 x--; foo(x);
 (So ++ and -- become similar to the Inc() and Dec() functions of Pascal).

 What problems such changes may cause?


 
 Apparently you want to change postInc/Dec to be statements to prevent them
from returning values (otherwise the expr semantics would need a special case).
That would break C compatibility and sounds ridiculous.


D's purpose is to break C compatibility.
Oct 25 2009
prev sibling next sibling parent "Peter C. Chapin" <pcc482719 gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote in
news:hc19h9$ih1$1 digitalmars.com: 


 Removing those operators from D, as Python, may look excessive. So a
 possible compromise can be: - Deprecate the pre versions:  --x  and
 ++x - Make them return void, so they can't be used as expressions like
 this: y = x++;


In C++, at least, I have often seen recommendations that say post 
increment/decrement should be avoided in favor of pre increment/decrement. 
The rational is that overloaded pre increment/decrement can be implemented 
more efficiently for complicated types---there is no need to create a 
temporary (you mutate the object and then return a reference to that same 
object). Thus I've trained myself to use pre incremenet/decrement 
throughout my C++ code except in cases where I explicitly need the post 
versions.

Of course what's good for C++ does not have to be good for D. However, 
deprecating the pre versions might turn off some potential D converts from 
the C++ community.

Peter
Oct 25 2009
prev sibling next sibling parent Justin Johansson <no spam.com> writes:
bearophile Wrote:


 This post is born from a bug I've just removed.
 In the past I have read more than one C coding standard (or better, lists of
coding tips) that warn against bugs caused by ++ and --. They suggest to not
use them compound in expressions. They allow to use them when alone on an
instruction.
 
 Python designers have totally avoided to put those operators in the language,
with the rationale they are bug-prone while saving just a little of typing.
 
 Removing those operators from D, as Python, may look excessive. So a possible
compromise can be:
 - Deprecate the pre versions:  --x  and ++x
 - Make them return void, so they can't be used as expressions like this:
 y = x++;
 foo(x--);
 You have to use them as:
 x++; y = x;
 x--; foo(x);
 (So ++ and -- become similar to the Inc() and Dec() functions of Pascal).
 
 What problems such changes may cause?
 
 Bye,
 bearophile


In the absence of optimization it is well known that pre-inc/dec operations are
faster that post-inc/dec operations by simple reason of the number of
memory-register-memory transfers required (at least historically this was so).

Accordingly since the year dot I have always coded my for loops like so:

for ( int i = 0; i < n; ++i) { ... }

rather than

for ( int i = 0; i < n; i++) { ... }

It would be easier for me to give up red wine than the pre-inc habit.

To me the proposal sounds over zealous.  I don't think much of
nanny-state governments either.

Cheers
Justin Johansson
Oct 25 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
bearophile wrote:


 This post is born from a bug I've just removed.
 In the past I have read more than one C coding standard (or better, lists
 of coding tips) that warn against bugs caused by ++ and --. They suggest
 to not use them compound in expressions. They allow to use them when alone
 on an instruction.
 
 Python designers have totally avoided to put those operators in the
 language, with the rationale they are bug-prone while saving just a little
 of typing.
 
 Removing those operators from D, as Python, may look excessive. So a
 possible compromise can be:
 - Deprecate the pre versions:  --x  and ++x
 - Make them return void, so they can't be used as expressions like this:
 y = x++;
 foo(x--);
 You have to use them as:
 x++; y = x;
 x--; foo(x);
 (So ++ and -- become similar to the Inc() and Dec() functions of Pascal).
 
 What problems such changes may cause?
 
 Bye,
 bearophile


It is way too patronizing. These operators are very well known by people 
with a C background and actually quite elegant if you are used to reading 
them, imho.
Oct 25 2009
prev sibling next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
bearophile wrote:

 Removing those operators from D, as Python, may look excessive. So a
 possible compromise can be: - Deprecate the pre versions:  --x  and
 ++x


There is nothing wrong with the prefix versions.  '--x' is the
equivalent of 'x -= 1', but with less excessive typing.  Any confusing
expression using prefix ++/-- will be just as confusing if rewritten to
use +=/-=.

On the other hand, there are two things wrong with the post versions:
  - They use postfix notation, unlike all other unary operators in D.
  - They have confusion semantics.

I don't use postfix ++/--.  I wouldn't mind if they were removed
entirely.  However, the prefix versions should be kept, and allowed in
compound expressions.


-- 
Rainer Deyke - rainerd eldwood.com
Oct 25 2009
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:


 Removing those operators from D, as Python, may look excessive. So a possible
compromise can be:
 - Deprecate the pre versions:  --x  and ++x
 - Make them return void, so they can't be used as expressions like this:
 y = x++;
 foo(x--);
 You have to use them as:
 x++; y = x;
 x--; foo(x);


int PreInc(ref int i){ i++; return i; }
int PostInc(ref int i){ i++; return i-1; }
y=PreInc(i);
y=PostInc(i);

just a little more difficult.

y=x=0;
Ever wondered what opAssign returns?
Oct 26 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Kagamin:


 int PreInc(ref int i){ i++; return i; }
 int PostInc(ref int i){ i++; return i-1; }
 y=PreInc(i);
 y=PostInc(i);
 
 just a little more difficult.


That's a vote for my proposal then, because you have shown a way to do the same
thing for people that really need to do it.

In D there are often ways to do everything. To help avoid bugs there's no need
to totally remove all ways to do something, but to turn them into something
explicit and under programmer's control. The idea is to turn places where
possible bugs can be hidden into something that can be seen.

Bye,
bearophile
Oct 26 2009
prev sibling parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:


 Python designers have totally avoided to put those operators in the language,
with the rationale they are bug-prone while saving just a little of typing.


In D you don't actually have to use them: you have ranges, foreaches etc.
Oct 26 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Kagamin:

 In D you don't actually have to use them: you have ranges, foreaches etc.


Very good, then restricting them will cause no problems.

Bye,
bearophile
Oct 26 2009
next sibling parent d-noob <doesnt exist.com> writes:
bearophile Wrote:


 Kagamin:

 In D you don't actually have to use them: you have ranges, foreaches etc.


 
 Very good, then restricting them will cause no problems.


He probably meant that the idea was to leave those parts of the language
untouched that don't really matter to you. You can write pythonese d just like
before and the rest of use can write in good old C/C++ fashion.
Oct 26 2009
prev sibling parent Kagamin <spam here.lot> writes:
bearophile Wrote:


 Kagamin:

 In D you don't actually have to use them: you have ranges, foreaches etc.


 
 Very good, then restricting them will cause no problems.


Why do you use feature if you feel uncomfortable with it? If I'm not familiar
with template voodoo, should I write TMP library and debug it?
Oct 26 2009