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