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


 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

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