void main()
{
  bit b1, b2, b3;
  b1=b2=!b3;
  if(b1) printf("true\n"); // prints 'true'
  // if(b1=!b3) printf("true\n");
  //error: '=' does not give a boolean result
}

In this case `=' yields a boolean.

So long.

I think = always returns a boolean result , it always returns true that the assignment succeeded right ?

I use assingment in conditional expressions alot this is one I miss too.

C

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:c0bebm$28bb$1@digitaldaemon.com...
> void main()
> {
>   bit b1, b2, b3;
>   b1=b2=!b3;
>   if(b1) printf("true\n"); // prints 'true'
>   // if(b1=!b3) printf("true\n");
>   //error: '=' does not give a boolean result
> }
>
> In this case `=' yields a boolean.
>
> So long.
>

Manfred Nowak wrote:

> void main()
> {
>   bit b1, b2, b3;
>   b1=b2=!b3;
>   if(b1) printf("true\n"); // prints 'true'
>   // if(b1=!b3) printf("true\n");
>   //error: '=' does not give a boolean result
> }
> 
> In this case `=' yields a boolean.
> 
> So long.
> 

Perhaps if the error message said that it wasn't a comparison instead of boolean, it would be more clear. It's to catch the common mistake of writing = when you actually meant to use ==. It caught me doing it a couple times (and I've written a LOT of D code), not very common, but could save a lot of frustration. Not to say that I'm for or against it; I don't mind either way.


-- 
Christopher E. Miller
www.dprogramming.com

Manfred Nowak wrote:
> In this case `=' yields a boolean.

This is an intentional plug, since any (human) code reviewer would flag assignment in an if as a probable bug. And it is one more often than not. The = unstead of == bug is really a plague, very hard to see and to debug once it's there.

-eye

Ilya Minkov wrote:
> 
> This is an intentional plug, since any (human) code reviewer would flag assignment in an if as a probable bug. And it is one more often than not. The = unstead of == bug is really a plague, very hard to see and to debug once it's there.

I'd rather this one be treated as a warning and have the phrasing changed a bit.  Assignments within if statements are quite common.

I don't suppose D supports declaration/assignments within if's?

if( int i = 5 ) {
    ...
}


Sean

> I don't suppose D supports declaration/assignments within if's?

No not supported.

"Sean Kelly" <sean@ffwd.cx> wrote in message news:c0biik$2fbj$1@digitaldaemon.com...
> Ilya Minkov wrote:
> >
> > This is an intentional plug, since any (human) code reviewer would flag assignment in an if as a probable bug. And it is one more often than not. The = unstead of == bug is really a plague, very hard to see and to debug once it's there.
>
> I'd rather this one be treated as a warning and have the phrasing changed a bit.  Assignments within if statements are quite common.
>
> I don't suppose D supports declaration/assignments within if's?
>
> if( int i = 5 ) {
>      ...
> }
>
>
> Sean
>

"C" <dont@respond.com> wrote in message news:c0bf0d$29h8$1@digitaldaemon.com... | I think = always returns a boolean result , it always returns true that the | assignment succeeded right ?

Assignment returns the lvalue for chaining - same as in C.

| I use assingment in conditional expressions alot this is one I miss too.
|
| C
|
| "Manfred Nowak" <svv1999@hotmail.com> wrote in message
| news:c0bebm$28bb$1@digitaldaemon.com...
| > void main()
| > {
| >   bit b1, b2, b3;
| >   b1=b2=!b3;
| >   if(b1) printf("true\n"); // prints 'true'
| >   // if(b1=!b3) printf("true\n");
| >   //error: '=' does not give a boolean result
| > }
| >
| > In this case `=' yields a boolean.
| >
| > So long.
| >
|
|

if (!(fp=fopen("filename","r")) { errmsg...; exit(1); }

is a very common C usage, and a few similar checks on returned values, but most of those will probably disappear in D, in favor of streams and better exception handling.  I don't see nearly as many reasonable usages in D.

-larry

In article <c0bhh0$2drt$1@digitaldaemon.com>, Ilya Minkov says...
>
>Manfred Nowak wrote:
>> In this case `=' yields a boolean.
>
>This is an intentional plug, since any (human) code reviewer would flag assignment in an if as a probable bug. And it is one more often than not. The = unstead of == bug is really a plague, very hard to see and to debug once it's there.
>
>-eye
>

I think it is not bug but specification.

if ( foo=bar)
may be typo of
if ( foo==bar)

If typo, it is bug in your code but difficult to find.
So, some C compiler such as GCC cause warning.
D cause error.

If you really want check lvalue(foo) is zero,write clearly
if ((foo=bar)!=0)
This way  is good even if C.

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:c0bebm$28bb$1@digitaldaemon.com...
> void main()
> {
>   bit b1, b2, b3;
>   b1=b2=!b3;
>   if(b1) printf("true\n"); // prints 'true'
>   // if(b1=!b3) printf("true\n");
>   //error: '=' does not give a boolean result
> }
>
> In this case `=' yields a boolean.
>
> So long.
>

BERO wrote:

[...]
> if ( foo=bar)
> may be typo of
> if ( foo==bar)
[...]
> If you really want check lvalue(foo) is zero,write clearly
> if ((foo=bar)!=0)

It is real fun to see how people try to circumvent bad language design once they have noticed it.

Because `foo=bar' might be a typo of `foo==bar' the solution would be to introduce something like `:=' for the assignment, then there would be no fear, that `foo:=bar' could be a typo of `foo==bar'.

Why does `if((foo=bar))' or `if(!(foo=bar))' still result in the error
`'=' does not give a boolean result', whereas `if((foo=bar)==true)' as
well as your recommendation compiles?

And why is it good to compare a boolean with an integer number?

According to my education holding assignment to and query of a variable
distinct is the better choice anyway. So to me clear writing would be
`foo:= bar; if(foo)' instead of `if((foo= bar) != 0)'.

And if `if(foo=bar)' produces an error because of the possibility of a typo, then the question raises why the statement `foo==bar;' does not produce an error: `foo==bar;' might be a typo of `foo=bar;'.

To me the answer for the raised question is very simple: the definition of the semantic of `=' in C, and therefore in D also, contradicts its semantic people learn in early ages: to be the comparison operator. So getting it wrong in an `if' statement and not finding it whenever it is there have a common reason.

So long.