Why is there no &&= nor ||= ind D?

bool foo;

So something like this should be possible:
foo &&= bar();

Matthias Becker wrote:

>Why is there no &&= nor ||= ind D?
>
>bool foo;
>
>So something like this should be possible:
>foo &&= bar();
>  
>
I can't see that being used much.  All that extra work for the compiler writer for little gain.

-- 
-Anderson: http://badmama.com.au/~anderson/

There is a bit of that in Dig, or at least

|=
and
&= ~

Phill.


"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c0elqc$1lme$1@digitaldaemon.com...
> Matthias Becker wrote:
>
> >Why is there no &&= nor ||= ind D?
> >
> >bool foo;
> >
> >So something like this should be possible:
> >foo &&= bar();
> >
> >
> I can't see that being used much.  All that extra work for the compiler writer for little gain.
>
> --
> -Anderson: http://badmama.com.au/~anderson/

>>Why is there no &&= nor ||= ind D?
>>
>>bool foo;
>>
>>So something like this should be possible:
>>foo &&= bar();
>> 
>>
>I can't see that being used much.  All that extra work for the compiler writer for little gain.

How often do you use %= ?

>There is a bit of that in Dig, or at least
>
>|=
>and
>&= ~
>
>Phill.

Yes, but they don't have this short cirquit behavior.

In article <c0fegm$2u05$1@digitaldaemon.com>, Matthias Becker wrote:
>>>Why is there no &&= nor ||= ind D?
>>>
>>>bool foo;
>>>
>>>So something like this should be possible:
>>>foo &&= bar();
>>> 
>>>
>>I can't see that being used much.  All that extra work for the compiler writer for little gain.
> 
> How often do you use %= ?

Occasionally. It's nice operator to have around when you want to modify the index to a circular buffer and keep it in the valid range.

But I've never thought of using &&=, maybe simply because there isn't one. And I've only seen &= used once or twice. Logically it makes sense, though, since almost all other operators have an assignment equivalent.

And "&&=" would provide one way of handling errors and cleaning up properly (if you don't want to use RAII or goto):

bool f()
{
    bool result = true;

    result &&= initialize();
    result &&= do_stuff();
    result &&= do_more_stuff();
    result &&= do_final_stuff();

    cleanup();
    return result;
}

If any of the functions fail, the functions after it won't be called.

On the other hand, I've often wanted to have a => operator.  "a => b"
would be equivalent to "!a || b". Using this instead of the usual
"if (a) b;" tickles my linguistic nerves in the same fashion as the perl
idiom "<do something> or die;". But maybe such syntactical sugar doesn't
belong in a serious language. ;)

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

In article <slrnc2ncfv.76a.jsykari@pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?= says...
>
>In article <c0fegm$2u05$1@digitaldaemon.com>, Matthias Becker wrote:
>>>>Why is there no &&= nor ||= ind D?
>>>>
>>>>bool foo;
>>>>
>>>>So something like this should be possible:
>>>>foo &&= bar();
>>>> 
>>>>
>>>I can't see that being used much.  All that extra work for the compiler writer for little gain.
>> How often do you use %= ?
>
>Occasionally. It's nice operator to have around when you want to modify the index to a circular buffer and keep it in the valid range.
>
>But I've never thought of using &&=, maybe simply because there isn't one. And I've only seen &= used once or twice. Logically it makes sense, though, since almost all other operators have an assignment equivalent.
>
>And "&&=" would provide one way of handling errors and cleaning up properly (if you don't want to use RAII or goto):
>
>bool f()
>{
>    bool result = true;
>
>    result &&= initialize();
>    result &&= do_stuff();
>    result &&= do_more_stuff();
>    result &&= do_final_stuff();
>
>    cleanup();
>    return result;
>}
>
>If any of the functions fail, the functions after it won't be called.
>
>On the other hand, I've often wanted to have a => operator.  "a => b"
>would be equivalent to "!a || b". Using this instead of the usual
>"if (a) b;" tickles my linguistic nerves in the same fashion as the perl
>idiom "<do something> or die;". But maybe such syntactical sugar doesn't
>belong in a serious language. ;)
>
>-Antti
>
>-- 
>I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

I must agree that there is no need for a &&= or ||= operator. Furthermore, I would also say that there shouldn't be a need for a && or || operator. Okay, after saying that I bet everyone is wondering "is he an idiot? Obviously he has no idea what he is talking about." So let me explain.

D provides operator overloading and as such should know that (uint) & (uint) is
not the same as (bool) & (bool). The reason why C and C++ have the && and ||
operator is because neither one has a true boolean type (in fact originally,
they didn't have one at all). Instead they define false to be zero, and true to
be everything else, thus the following code is legal:

int x;
int y;
/* do something */
if (x && (y > 0)) /* do something */

The && operator tells the compiler that the previous subexpression was a check agaist zero. Arguably, code like this should be illegal. Yes, I'll admit I may have used the implicit check against zero on several occassions myself, but it really is less readable and maintainable. The language should enforce all expressions within an if condition or loop condition to be of type Boolean. If indeed we do enforce that, then that same code would be written as:

int x;
int y;
/* do something */
if ((x != 0) && (y > 0)) /* do something */

Here, there is no longer any ambiguity as to what the programmer intended. We have a boolean and-ed with a boolean. Since boolean is built in, the compiler should know to only execute the second part if the first part evaluates to true.

Now, what this doesn't let you do is to use the non short-circut condition that is also available in C/C++. But lets be honest, how many times have you had the nead to use it. I myself cannot say I've ever had the need to use it. In fact, most people aren't even aware of it, and can also lead to more maintainability problems. So for example the following two statements are legal in C and C++, but are *not* equivalanet

if ( (x != 0) && fn() ) /* do something */
if ( (x != 0) & fn() ) /* do something */

In the first case, fn is called if and only if x != 0. In the second case, fn is called regardless of the value of x! This is the type of mistake that can go unnoticed by a the programmer or a code review, but hopefully a lint program will catch. (If you don't know what lint is, I suggest you find and use it! PC-Lint by Gimpel software is quite good: www.gimpel.com)

- Eric

You'd better come up with a better example.

<snip>
>bool f()
>{
>    bool result = true;
>
>    result &&= initialize();
>    result &&= do_stuff();
>    result &&= do_more_stuff();
>    result &&= do_final_stuff();
>
>    cleanup();
>    return result;
>}
>
>If any of the functions fail, the functions after it won't be called.
>
</snip>

I've used (when I was very young) something more like:

bool f()
{
bool result = true;

result = initialize() &&
do_stuff()        &&
do_more_stuff()   &&
do_final_stuff()  ;

cleanup();
return result;
}

or

bool f()
{
bool result = true;

if ( initialize()      &&
do_stuff()        &&
do_more_stuff()   &&
do_final_stuff() )
{
// Meat of the matter
}

cleanup();
return result;
}

but this is all poor style anyway as the cause of the problem is hidden. And try/catch exception handling should be used instead:

bool f()
{
bool result = true ;

try
{
initialize() ;
do_stuff() ;
do_more_stuff() ;
do_final_stuff() ;
}
catch ( ... )
{
// handle the exception
result = false ;
}
finally
{
cleanup() ;
}

return result ;
}

On Thu, 12 Feb 2004 18:03:08 +0000 (UTC) (02/13/04 05:03:08)
, <edgein123@aol.com> wrote:

> In article <slrnc2ncfv.76a.jsykari@pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?=

[snip]

> I must agree that there is no need for a &&= or ||= operator. Furthermore, I
> would also say that there shouldn't be a need for a && or || operator. Okay,
> after saying that I bet everyone is wondering "is he an idiot? Obviously he has
> no idea what he is talking about." So let me explain.
>
> D provides operator overloading and as such should know that (uint) & (uint) is
> not the same as (bool) & (bool). The reason why C and C++ have the && and ||
> operator is because neither one has a true boolean type (in fact originally,
> they didn't have one at all). Instead they define false to be zero, and true to
> be everything else, thus the following code is legal:
>
> int x;
> int y;
> /* do something */
> if (x && (y > 0)) /* do something */
>
> The && operator tells the compiler that the previous subexpression was a check
> agaist zero. Arguably, code like this should be illegal. Yes, I'll admit I may
> have used the implicit check against zero on several occassions myself, but it
> really is less readable and maintainable. The language should enforce all
> expressions within an if condition or loop condition to be of type Boolean. If
> indeed we do enforce that, then that same code would be written as:
>
> int x;
> int y;
> /* do something */
> if ((x != 0) && (y > 0)) /* do something */
>
> Here, there is no longer any ambiguity as to what the programmer intended. We
> have a boolean and-ed with a boolean. Since boolean is built in, the compiler
> should know to only execute the second part if the first part evaluates to true.

There is some merit in what you say. I like program code to be explict in showing the programmer's intentions.

> Now, what this doesn't let you do is to use the non short-circut condition that
> is also available in C/C++. But lets be honest, how many times have you had the
> nead to use it. I myself cannot say I've ever had the need to use it. In fact,
> most people aren't even aware of it, and can also lead to more maintainability
> problems. So for example the following two statements are legal in C and C++,
> but are *not* equivalanet
>
> if ( (x != 0) && fn() ) /* do something */
> if ( (x != 0) & fn() ) /* do something */
>
> In the first case, fn is called if and only if x != 0. In the second case, fn is
> called regardless of the value of x! This is the type of mistake that can go
> unnoticed by a the programmer or a code review, but hopefully a lint program
> will catch.

Actually, I rather use the short-circuit feature a lot. Especially in this sort of case ...

  if ( (index >= 0) && (index <= maxsize) && (myArray[index] = target))
  {
    /* do something */
  }
  else
  {
     /* Not an error, but just ignored. */
  }

-- 
Derek

In article <opr291uej9yj5swd@news.digitalmars.com>, Derek Parnell says...
>
>On Thu, 12 Feb 2004 18:03:08 +0000 (UTC) (02/13/04 05:03:08)
>, <edgein123@aol.com> wrote:
>
>> In article <slrnc2ncfv.76a.jsykari@pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?=
>
>[snip]
>
>> I must agree that there is no need for a &&= or ||= operator.
>> Furthermore, I
>> would also say that there shouldn't be a need for a && or || operator.
>> Okay,
>> after saying that I bet everyone is wondering "is he an idiot? Obviously
>> he has
>> no idea what he is talking about." So let me explain.
>>
>> D provides operator overloading and as such should know that (uint) &
>> (uint) is
>> not the same as (bool) & (bool). The reason why C and C++ have the &&
>> and ||
>> operator is because neither one has a true boolean type (in fact
>> originally,
>> they didn't have one at all). Instead they define false to be zero, and
>> true to
>> be everything else, thus the following code is legal:
>>
>> int x;
>> int y;
>> /* do something */
>> if (x && (y > 0)) /* do something */
>>
>> The && operator tells the compiler that the previous subexpression was a
>> check
>> agaist zero. Arguably, code like this should be illegal. Yes, I'll admit
>> I may
>> have used the implicit check against zero on several occassions myself,
>> but it
>> really is less readable and maintainable. The language should enforce all
>> expressions within an if condition or loop condition to be of type
>> Boolean. If
>> indeed we do enforce that, then that same code would be written as:
>>
>> int x;
>> int y;
>> /* do something */
>> if ((x != 0) && (y > 0)) /* do something */
>>
>> Here, there is no longer any ambiguity as to what the programmer
>> intended. We
>> have a boolean and-ed with a boolean. Since boolean is built in, the
>> compiler
>> should know to only execute the second part if the first part evaluates
>> to true.
>
>There is some merit in what you say. I like program code to be explict in showing the programmer's intentions.
>
>> Now, what this doesn't let you do is to use the non short-circut
>> condition that
>> is also available in C/C++. But lets be honest, how many times have you
>> had the
>> nead to use it. I myself cannot say I've ever had the need to use it. In
>> fact,
>> most people aren't even aware of it, and can also lead to more
>> maintainability
>> problems. So for example the following two statements are legal in C and
>> C++,
>> but are *not* equivalanet
>>
>> if ( (x != 0) && fn() ) /* do something */
>> if ( (x != 0) & fn() ) /* do something */
>>
>> In the first case, fn is called if and only if x != 0. In the second
>> case, fn is
>> called regardless of the value of x! This is the type of mistake that
>> can go
>> unnoticed by a the programmer or a code review, but hopefully a lint
>> program
>> will catch.
>
>Actually, I rather use the short-circuit feature a lot. Especially in this sort of case ...
>
>   if ( (index >= 0) && (index <= maxsize) && (myArray[index] = target))
>   {
>     /* do something */
>   }
>   else
>   {
>      /* Not an error, but just ignored. */
>   }
>
>-- 
>Derek
My point was that programmers almost always use, and rely on, the short circuit evaluation. I probably should been clearer that I meant most programmers do not use the form "if ((expression1) & (expression2))." In fact it is hard to imagine a case where you do NOT want short circuit evaluation, and for any such case there is always a better way to code it.