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.

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.