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

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

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

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?

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

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

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

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

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.

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