www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Rationale for not allowing overload of && and ||?

reply Joe Gauterin <Joseph.Gauterin googlemail.com> writes:
What is the rationale for not allowing overloading of && and ||? It seems to me
that, with the 'lazy' keyword, D is one of the few languages where overloaded
&& and || can correctly implement short circuited evaluation.
Jun 18 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Joe Gauterin" <Joseph.Gauterin googlemail.com> wrote in message 
news:g3bpl0$1ujc$1 digitalmars.com...

 What is the rationale for not allowing overloading of && and ||? It seems 
 to me that, with the 'lazy' keyword, D is one of the few languages where 
 overloaded && and || can correctly implement short circuited evaluation.


If I'm not mistaken, I think you can define an "implicit conversion from 
this class (or struct?) to ...".  So I assume the reason is, defining an 
implicit conversion to bool would effectively eliminate all (legitamate) 
reasons to overload && and ||. The only things that overloading && and || 
could do that couldn't be accomplished (with better compatability across 
various types) would be things that would break the intended meaning of && 
and ||. Buy that's considered bad style when overloading operators anyway.
Jun 18 2008
parent reply Brian Price <blprice61 yahoo.com> writes:
Nick Sabalausky Wrote:


 "Joe Gauterin" <Joseph.Gauterin googlemail.com> wrote in message 
 news:g3bpl0$1ujc$1 digitalmars.com...

 What is the rationale for not allowing overloading of && and ||? It seems 
 to me that, with the 'lazy' keyword, D is one of the few languages where 
 overloaded && and || can correctly implement short circuited evaluation.


 
 If I'm not mistaken, I think you can define an "implicit conversion from 
 this class (or struct?) to ...".  So I assume the reason is, defining an 
 implicit conversion to bool would effectively eliminate all (legitamate) 
 reasons to overload && and ||. The only things that overloading && and || 
 could do that couldn't be accomplished (with better compatability across 
 various types) would be things that would break the intended meaning of && 
 and ||. Buy that's considered bad style when overloading operators anyway. 
 


 
Bayesian and fuzzy logic both assign non boolean meanings to the operations
and/or.  If you cannot overload && and || you cannot express such logic
operations in a concise recognizable form.  

Brian
Jun 18 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Brian Price" <blprice61 yahoo.com> wrote in message 
news:g3brj5$2370$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "Joe Gauterin" <Joseph.Gauterin googlemail.com> wrote in message
 news:g3bpl0$1ujc$1 digitalmars.com...

 What is the rationale for not allowing overloading of && and ||? It 
 seems
 to me that, with the 'lazy' keyword, D is one of the few languages 
 where
 overloaded && and || can correctly implement short circuited 
 evaluation.


 If I'm not mistaken, I think you can define an "implicit conversion from
 this class (or struct?) to ...".  So I assume the reason is, defining an
 implicit conversion to bool would effectively eliminate all (legitamate)
 reasons to overload && and ||. The only things that overloading && and ||
 could do that couldn't be accomplished (with better compatability across
 various types) would be things that would break the intended meaning of 
 &&
 and ||. Buy that's considered bad style when overloading operators 
 anyway.


 Bayesian and fuzzy logic both assign non boolean meanings to the 
 operations and/or.  If you cannot overload && and || you cannot express 
 such logic operations in a concise recognizable form.

 Brian


I stand corrected :)
Jun 18 2008
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Brian Price" <blprice61 yahoo.com> wrote in message 
news:g3brj5$2370$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "Joe Gauterin" <Joseph.Gauterin googlemail.com> wrote in message
 news:g3bpl0$1ujc$1 digitalmars.com...

 What is the rationale for not allowing overloading of && and ||? It 
 seems
 to me that, with the 'lazy' keyword, D is one of the few languages 
 where
 overloaded && and || can correctly implement short circuited 
 evaluation.


 If I'm not mistaken, I think you can define an "implicit conversion from
 this class (or struct?) to ...".  So I assume the reason is, defining an
 implicit conversion to bool would effectively eliminate all (legitamate)
 reasons to overload && and ||. The only things that overloading && and ||
 could do that couldn't be accomplished (with better compatability across
 various types) would be things that would break the intended meaning of 
 &&
 and ||. Buy that's considered bad style when overloading operators 
 anyway.


 Bayesian and fuzzy logic both assign non boolean meanings to the 
 operations and/or.  If you cannot overload && and || you cannot express 
 such logic operations in a concise recognizable form.


& and |?
Jun 18 2008
parent reply Brian Price <blprice61 yahoo.com> writes:
Jarrett Billingsley Wrote:


 "Brian Price" <blprice61 yahoo.com> wrote in message 
 news:g3brj5$2370$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "Joe Gauterin" <Joseph.Gauterin googlemail.com> wrote in message
 news:g3bpl0$1ujc$1 digitalmars.com...

 What is the rationale for not allowing overloading of && and ||? It 
 seems
 to me that, with the 'lazy' keyword, D is one of the few languages 
 where
 overloaded && and || can correctly implement short circuited 
 evaluation.


 If I'm not mistaken, I think you can define an "implicit conversion from
 this class (or struct?) to ...".  So I assume the reason is, defining an
 implicit conversion to bool would effectively eliminate all (legitamate)
 reasons to overload && and ||. The only things that overloading && and ||
 could do that couldn't be accomplished (with better compatability across
 various types) would be things that would break the intended meaning of 
 &&
 and ||. Buy that's considered bad style when overloading operators 
 anyway.


 Bayesian and fuzzy logic both assign non boolean meanings to the 
 operations and/or.  If you cannot overload && and || you cannot express 
 such logic operations in a concise recognizable form.


 
 & and |? 
 
 


That is, of course, the workaround.  However bitwise-and does not mean logical
and, nor bitwise-or mean logical or, so you are forced to use a syntax that is
semantically incorrect.  That is, if you want the convenience of using
operators.

Brian
Jun 18 2008
parent Joe Gauterin <Joseph.Gauterin googlemail.com> writes:
Brian Price Wrote:


 Jarrett Billingsley Wrote:
 

 "Brian Price" <blprice61 yahoo.com> wrote in message 
 news:g3brj5$2370$1 digitalmars.com...

 Nick Sabalausky Wrote:


 "Joe Gauterin" <Joseph.Gauterin googlemail.com> wrote in message
 news:g3bpl0$1ujc$1 digitalmars.com...

 What is the rationale for not allowing overloading of && and ||? It 
 seems
 to me that, with the 'lazy' keyword, D is one of the few languages 
 where
 overloaded && and || can correctly implement short circuited 
 evaluation.


 If I'm not mistaken, I think you can define an "implicit conversion from
 this class (or struct?) to ...".  So I assume the reason is, defining an
 implicit conversion to bool would effectively eliminate all (legitamate)
 reasons to overload && and ||. The only things that overloading && and ||
 could do that couldn't be accomplished (with better compatability across
 various types) would be things that would break the intended meaning of 
 &&
 and ||. Buy that's considered bad style when overloading operators 
 anyway.


 Bayesian and fuzzy logic both assign non boolean meanings to the 
 operations and/or.  If you cannot overload && and || you cannot express 
 such logic operations in a concise recognizable form.


 
 & and |? 
 
 


 That is, of course, the workaround.  However bitwise-and does not mean logical
and, nor bitwise-or mean logical or, so you are forced to use a syntax that is
semantically incorrect.  That is, if you want the convenience of using
operators.
 
 Brian
 


So there's no real reason? Presumably it's just a hangover from when D didn't
have the 'lazy' keyword or an aversion to overloading them due to the mess C++
makes of it.
Jun 23 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Joe Gauterin Wrote:

 What is the rationale for not allowing overloading of && and ||? It seems to
me that, with the 'lazy' keyword, D is one of the few languages where
overloaded && and || can correctly implement short circuited evaluation.


Maybe you are talking about the lazy or/and of languages like Python. I have
created lazyAnd(), lazyOr() in my libs, and I think I like them more explicitly
named, to avoid confusion. They are shaped like:

Types[0] lazyAnd(Types...)(lazy Types items) {
    // some static asserts here to avoid some problems
    foreach (el; items[0 .. $-1])
        if (not(el))
            return el;
    return items[$-1];
}

Where not() is a boolean that is true/false if the item is 0, 0.0, null, an
empty array, an empty set, empty AA, something with length zero, etc etc.

Bye,
bearophile
Jun 18 2008
parent reply BCS <ao pathlink.com> writes:
Reply to bearophile,


 Joe Gauterin Wrote:
 

 What is the rationale for not allowing overloading of && and ||? It
 seems to me that, with the 'lazy' keyword, D is one of the few
 languages where overloaded && and || can correctly implement short
 circuited evaluation.
 


 I have created lazyAnd(), lazyOr() in my libs, and I think I like them
 more explicitly named, to avoid confusion. They are shaped like:
 


|| and && are lazy in D


What does your provide that the native one don't?
Jun 18 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"BCS" <ao pathlink.com> wrote in message 
news:55391cb32e4e58ca9f630a69297e news.digitalmars.com...

 Reply to bearophile,


 Joe Gauterin Wrote:


 What is the rationale for not allowing overloading of && and ||? It
 seems to me that, with the 'lazy' keyword, D is one of the few
 languages where overloaded && and || can correctly implement short
 circuited evaluation.


 I have created lazyAnd(), lazyOr() in my libs, and I think I like them
 more explicitly named, to avoid confusion. They are shaped like:


 || and && are lazy in D


 What does your provide that the native one don't?


It returns the value instead of the value converted to a bool.
Jun 18 2008