My new favorite D feature

[Steve Horne]

On Sat, 23 Dec 2006 13:24:55 +0900, Bill Baxter <wbaxter at 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.