digitalmars.D - My new favorite D feature
- Tim Keating <holyspamster gmail.com> Dec 19 2006
- Gregor Richards <Richards codu.org> Dec 19 2006
- BCS <BCS pathilink.com> Dec 19 2006
- alex4u2nv <blight gmail.com> Dec 20 2006
- Pragma <ericanderton yahoo.removeme.com> Dec 20 2006
- "Bob W" <nospam aol.com> Dec 21 2006
- BCS <BCS pathlink.com> Dec 21 2006
- Tim Keating <holyspamster gmail.com> Dec 21 2006
- Steve Horne <stephenwantshornenospam100 aol.com> Dec 22 2006
- Bill Baxter <wbaxter gmail.com> Dec 22 2006
- Steve Horne <stephenwantshornenospam100 aol.com> Dec 22 2006
- Walter Bright <newshound digitalmars.com> Dec 22 2006
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
Gregor Richards <Richards codu.org> 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
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
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
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
"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
Bob W wrote:"Tim Keating" <holyspamster gmail.com> wrote in message
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
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
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
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
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
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