www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - My new favorite D feature

reply Tim Keating <holyspamster gmail.com> writes:
At least for then next couple of hours, anyway:

	int i = 100;

	if (i = 2);
	{
		writefln("We shouldn't be here");
	}

Yields:

	use '{ }' for an empty statement, not a ';'

Instead of blithely steping into that block. As just happened in my C++ 
program, wasting 30 minutes of my life while I tried to figure out why 
the heck that block kept getting executed.

TK
Dec 19 2006
next sibling parent Gregor Richards <Richards codu.org> writes:
Tim Keating wrote:

 At least for then next couple of hours, anyway:
 
 	int i = 100;
 
 	if (i = 2);
 	{
 		writefln("We shouldn't be here");
 	}
 
 Yields:
 
 	use '{ }' for an empty statement, not a ';'
 
 Instead of blithely steping into that block. As just happened in my C++ 
 program, wasting 30 minutes of my life while I tried to figure out why 
 the heck that block kept getting executed.
 
 TK


This has actually annoyed me a bit, but not enough to think it's not 
worth it.

for (i = 0; foo[i] != TERMINATOR; i++);

  - Gregor Richards
Dec 19 2006
prev sibling next sibling parent reply BCS <BCS pathilink.com> writes:
Tim Keating wrote:

 At least for then next couple of hours, anyway:
 
 	int i = 100;
 
 	if (i = 2)
 	{
 		writefln("We shouldn't be here");
 	}
 
 Yields:
 


  Error: '=' does not give a boolean result

another good one
Dec 19 2006
parent reply alex4u2nv <blight gmail.com> writes:
Im new to this language and just getting aquainted, but what happens in the
scenario of saving and evaluating the return value of a function within the if
statement to be used elsewhere.

bool search() { //find something; if (..) return index; else return 0;//not
found }

if ( retval = search() )
   {
     writefln("found:");
     writefln(retval);
   } else {
     writefln( "not found" );
   }


// or something similar?
Dec 20 2006
parent Pragma <ericanderton yahoo.removeme.com> writes:
alex4u2nv wrote:

 Im new to this language and just getting aquainted, but what happens in the
 scenario of saving and evaluating the return value of a function within the if
 statement to be used elsewhere.
 
 bool search() { //find something; if (..) return index; else return 0;//not
found }
 
 if ( retval = search() )
    {
      writefln("found:");
      writefln(retval);
    } else {
      writefln( "not found" );
    }
 
 
 // or something similar?


You have to make it look like a variable declaration at the same time, 
thus forcing you to be more explicit:

if(auto retval = search()){ /*...*/ }

The operative word here is 'explicit': it's impossible to confuse with 
simply forgetting that extra '='.

However, the only drawback here is that the variable used in the if() 
statement is scoped to the if()'s true branch.  It's all here:

http://www.digitalmars.com/d/statement.html#IfStatement

-- 
- EricAnderton at yahoo
Dec 20 2006
prev sibling next sibling parent reply "Bob W" <nospam aol.com> writes:
"Tim Keating" <holyspamster gmail.com> wrote in message 
news:MPG.1ff2693c84944836989681 news.digitalmars.com...

 At least for then next couple of hours, anyway:

 int i = 100;

 if (i = 2);
 {
 writefln("We shouldn't be here");
 }

 Yields:

 use '{ }' for an empty statement, not a ';'


What's wrong with that message?
(I didn't get your joke here - if it was one.)

Removing the ';'  after (i = 2)  should put you in
a better position to get another message:

if (i = 2)
{
    writefln("We shouldn't be here");
}


"Error: '=' does not give a boolean result"

Since you'd probably prefer your program to
actually wotk, you might even want to try this:

if (i == 2)
{
    writefln("We shouldn't be here");
}

But as I mentioned initially - I probably didn't catch
the joke ...
Dec 21 2006
parent reply BCS <BCS pathlink.com> writes:
Bob W wrote:

 "Tim Keating" <holyspamster gmail.com> wrote in message 


[My new favorite D feature]

At least for then next couple of hours, anyway:


 
 But as I mentioned initially - I probably didn't catch
 the joke ...
 


No joke. I think He's saying he likes that feature.

Just read it literally
Dec 21 2006
parent reply Tim Keating <holyspamster gmail.com> writes:
In article <emeln6$25q3$1 digitaldaemon.com>, BCS pathlink.com says...

 Bob W wrote:
 No joke. I think He's saying he likes that feature.
 
 Just read it literally


Yup. I complicated the example by using '=' instead of '==', which, as 
has been pointed out, is another way that D helps you avoid shooting 
yourself in the foot.

TK
Dec 21 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Thu, 21 Dec 2006 23:39:39 -0600, Tim Keating
<holyspamster gmail.com> wrote:


In article <emeln6$25q3$1 digitaldaemon.com>, BCS pathlink.com says...

 Bob W wrote:
 No joke. I think He's saying he likes that feature.
 
 Just read it literally


Yup. I complicated the example by using '=' instead of '==', which, as 
has been pointed out, is another way that D helps you avoid shooting 
yourself in the foot.


Yeah, but I'm not quite so keen. I like being able to use assignments
within expressions (in moderation, of course).

Personally, I think there are two sane options for programming
languages...

1 : Allowing assignments in expressions :
    - Use := for assignment and == for equality testing
    - The = operator should be recognised, but should always give an
      error

2 : Disallowing assignments in expressions :
    - Use a single = operator

The first option in particular makes a lot of sense if you've spent
most of the last 20 years regularly switching back and forth between C
and Pascal family languages.

Of course you can still confuse := and ==, in theory. But it is pretty
unlikely. Confusion isn't limited to these operators anyway. Consider
operators like +=. Whichever of the two characters you miss, you get
code that's legal but wrong. Finger trouble can always cause confusion
in any language. There comes a point where the programmer has to take
responsibility.

It's just that the = operator is an particular annoyance since it
means different things in Pascal and C family languages, and is
'overloaded' to mean both in languages like Basic, and all of these
different approaches are 'the right way' to a lot of people.

As for case 2, if there's no context where both operators are legal,
there's no point having two operators, so you may as well go the Basic
route and overload a single operator. I'm all for expressing
intentions explicitly, but that doesn't mean pointless pedanticism. We
are happy to have other kinds of overloading in the language, after
all, and decades of experience show that having a single = operator
causes no problems at all in the languages that work that way. It
simply means there's no way to write assignments in expressions,
saving the hassle of banning them.

The trouble is, it breaks my prime directive. Don't start changing
fundamental operators around once a language is in use. The kind of
chaos that would cause...

It was bad enough when Python changed its division operator :-(

-- 
Remove 'wants' and 'nospam' from e-mail.
Dec 22 2006
parent reply Bill Baxter <wbaxter gmail.com> writes:
Steve Horne wrote:

 On Thu, 21 Dec 2006 23:39:39 -0600, Tim Keating
 <holyspamster gmail.com> wrote:
 
 

In article <emeln6$25q3$1 digitaldaemon.com>, BCS pathlink.com says...


Bob W wrote:
No joke. I think He's saying he likes that feature.

Just read it literally


Yup. I complicated the example by using '=' instead of '==', which, as 
has been pointed out, is another way that D helps you avoid shooting 
yourself in the foot.


 
 
 Yeah, but I'm not quite so keen. I like being able to use assignments
 within expressions (in moderation, of course).
 
 Personally, I think there are two sane options for programming
 languages...


What's so bad about  if((a=b)!=0)  ?
--bb
Dec 22 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Sat, 23 Dec 2006 13:24:55 +0900, Bill Baxter <wbaxter gmail.com>
wrote:


Steve Horne wrote:



 Yeah, but I'm not quite so keen. I like being able to use assignments
 within expressions (in moderation, of course).
 
 Personally, I think there are two sane options for programming
 languages...


What's so bad about  if((a=b)!=0)  ?
--bb


OK, so you're writing some experimental code, and the code has a
conditional that should be as follows...

  if ((a == b) != precalculated_flag)

But due to confusion or finger trouble, you actually write...

  if ((a = b) != precalculated_flag)

Later, you discover that you don't need that saved flag variable, so
you search-and-replace to put the fixed 'false' value everywhere the
flag was referenced. Only because you're older than the hills and used
C to program your abacus back before boolean types were invented, you
use '0' instead of 'false'.

End result - you have your example precisely...

  if ((a = b) != 0)

but it isn't what you want, as you intended...

  if ((a == b) != 0)

Now personally, I can't see the difference between that and having...

  if (a = b)

where you intend...

  if (a == b)

Of course, I guess the real point you're making is that it's possible
to use an assignment in an expression in D - it's just that there are
a few specific contexts where the assignment is explicitly recognised
and banned, and a few extra brackets can overcome that.

I still think that's a bit broken, though...

1.  There's no strong reason why = and == are particularly confusable
    in some expression contexts but not others.

2.  If there is a context that's more problematic, it's deeply nested
    in a complex expression, not at the top level in a trivial
    expression that is easy to read and understand.

    I often use both equality tests and assignments deeply nested in
    expressions. A simple 'if (a == b)' style test is very rare in my
    code - a test like that would probably become one case of a switch
    statement.

3.  It means there are different rules for different expressions
    (or subexpressions, at least), which seems very very wrong to me.

So I stick with my view that the = operator is just too ambiguous, and
in any fresh new language that needs distinct equality and assignment
operators it should be avoided. And since there are obvious
unambiguous alternatives for both assignment and equality testing,
that's no problem at all.

It's just a moot point, as I said, since D is not a fresh new
language. OK, it's relatively new, but there's still a lot of code
about. And assignment and equality are emphatically not rare
operators.

Given that, D is probably doing the right thing by trying to spot the
most common mistakes without banning assignments in expressions
altogether. A test that gives false positives and false negatives may
still be useful, and despite my reservations, I have no doubt that Ds
approach will catch real errors, and that's always a good thing.

-- 
Remove 'wants' and 'nospam' from e-mail.
Dec 22 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Tim Keating wrote:

 At least for then next couple of hours, anyway:
 
 	int i = 100;
 
 	if (i = 2);
 	{
 		writefln("We shouldn't be here");
 	}
 
 Yields:
 
 	use '{ }' for an empty statement, not a ';'
 
 Instead of blithely steping into that block. As just happened in my C++ 
 program, wasting 30 minutes of my life while I tried to figure out why 
 the heck that block kept getting executed.


That feature is in there, because way back in 1984 or so, a friend of 
mine (who is a top programmer) spent several hours with code that looked 
like:

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

wondering why his loop executed exactly once.
Dec 22 2006