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 |?

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 |?

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.
 

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.

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